@culvert26 янв 2012 в 13:25

Multithreading in practice

9 мин

36K

Java *

+38

Комментарии 17

@romik 26 янв 2012 в 14:05

По коду:
1. BacklogThreadPool.sequence инкрементится непотокобезопасно, лучше убрать volatile, а getSequence сделать static synchronized. Хотя здесь это, конечно, совершенно некритично.
2. Я на 100% уверен, что CasCounter будет работать медленнее, поскольку CAS всё равно эмулируется через synchronized, а операция сложения явно проще чем сравнение и условное присваивание.

Ну и, естественно, вертящийся на языке вопрос: зачем в реальной жизни нужно условие не использовать java.util.concurrent кроме как для поддержки чего-нибудь на Java 1.4

@return_true 26 янв 2012 в 14:49

В лабораторных работах, в тестовых заданиях бывает просят не пользоваться частью библиотек.

@culvert 26 янв 2012 в 15:13

1. поправил
2. я хотел показать как работает Atomic, CasCounter действительно работает медленее, но не сильно.

Почему такое условие было поставленно не знаю, думаю это задание либо на собеседование, либо по учебе, и хотят посмотреть как человек понимает многопоточность.

@csscat 27 янв 2012 в 07:24

Да, согласен, условие жестокое :)

@r_ii 26 янв 2012 в 15:54

Насколько я вижу у Вас задача «работа с файловой системой» и задача «парсинг имен» обрабатываются однотипно. Очевидно (если отбросить файловый кеш операционной системы), что чтение списка файлов будет являться бутылочным горлышком. Поэтому лучше будет читать список файлов последовательно в отдельном потоке, а парсинг имен производить в пуле потоков.

@culvert 26 янв 2012 в 18:33

Да, в принципе этот подход возможен, но процент времени, которое тратит процессор на IO и на парсер не соизмерими IO >> parse, Тем более это сильно зависит от OS, к примеру win7 в принципе держит кэш файловой системы, поэтому производительность однопоточного решения будет менее выгодно.

@r_ii 26 янв 2012 в 19:15

Ну это зависит от того в каких условиях чаще всего будет применяться алгоритм. Попробуйте запустить Ваше решение на компакт-диске с большим количеством файлов/папок ;)
Вообще думаю лучше всего было-бы использовать средства фильтрации ОС если условие совпадения endswith.

@culvert 26 янв 2012 в 21:41

Все правильно, тут надо решение подводить под конкретную ситуацию, к примеру если это запустить на SSD, то мне кажется, что однопоточное решение на IO будет медленней, чем многопоточное, но если запускать на CD/DVD, то однопоточное решение будет быстрее.

НЛО прилетело и опубликовало эту надпись здесь

@culvert 26 янв 2012 в 18:30

была описана как работает в принципе Atomic, как работает JIT уже не так важно. К примеру на одном собеседовании у меня однажды спросили именно как работает Atomic, ответ — JIT в момент компиляции разворачивает вызовы Unsafe в конкретные наборы команд на целевой архитектуре врят ли бы устроил :)

НЛО прилетело и опубликовало эту надпись здесь

@elw00d 27 янв 2012 в 06:21

Не совсем понял, как вы изначально добавляете таски — берете первую директорию и примерно делите её список поддиректорий на N частей, где N = кол-во ядер процессора * 4?
По поводу проблемы аггрегации результатов с выполненных тасков — тут вроде бы подходит способ, пропагандируемый fork-join framework.

@aymeshkov 27 янв 2012 в 06:58

Удивился что не используется Semaphore в worker'ах, потом вспомнил про запрет на util.concurrent.
Хотя он достаточно легко реализуется через wait-notify, и отлично ложится на задачу,
реализация ThreadPool'а получилась бы намного короче и понятнее.

@AllySanders 10 фев 2012 в 21:37

public class WalkinTask1 implements BacklogTask
а где взять интерфейс BacklogTask?

@AllySanders 10 фев 2012 в 21:40

нашел… линк в конце статьи.

@AllySanders 12 фев 2012 в 15:16

почему-то все потоки весят в wait после того как все поддиректории обработаны.

@AllySanders 12 фев 2012 в 17:27

выяснил, что проблема в последней строке этого куска кода (класс BacklogWorker):

 for (int i = 0; i < INITIAL_CAPACITY && i < size; i++) {

 workQueue.add(backlog.poll());

 }

 backlog.clear();

да и странно как-то… выбрали из бэклога INITIAL_CAPACITY задач (в случае, если их больше там), а остальные удалили. После того как закомментировал эту строку, программа завершается корректно.

правда и результаты другие. если взять время выполнения createSingleWalkinTask за 100%, то createWalkingTask выполняется за 87%, а createWalking1Task — 83% времени.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий