-
Notifications
You must be signed in to change notification settings - Fork 0
Home
В данном задании необходимо было реализовать блокировку выполнения одного потока, пока не завершится N остальных. В целом, для этой задачи лучше всего подходит CountDownLatch (или Phaser), но почему бы не провести эксперимент?)
CountDownLatch
Подходит лучше всего, самым первым приходит в голову при выборе подходящего инструмента. CountDownLatch предназначен для блокирования выполнения одного потока пока не будут выполнено определенное количество операций. В нашем случае у нас должно быть выполнено 5 операций, только после выполнения которых должна быть возобновлена работа Consumer’a.
Количество строк: 3
Количество дополнительных объектов: 1 (собственно, CountDownLatch)
Масштабируемость:
Скорость выполнения:
CyclicBarrier
Циклический барьер тоже неплох для реализации данной задачи.
Количество строк:
Количество дополнительных объектов:
Масштабируемость:
Скорость выполнения:
Semaphore
Количество строк:
Количество дополнительных объектов:
Масштабируемость:
Скорость выполнения:
Exchanger
!!! ВНИМАНИЕ !!!
Сделано ради фана. Концептуально Exchange сюда подходит чуть менее, чем никак. Но - хэй, почему бы не попробовать?)
Количество строк:
Количество дополнительных объектов:
Масштабируемость:
Скорость выполнения:
Phaser
Стильный модный молодёжный Phaser будет хорошо смотреться, когда заказчики "слегка" изменят условия задачи. Остальные плюсы у него такое же как у CountDownLatch. Он немного избыточен для решения конкретно этой задачи, но если делать задел на будущее - почему бы и нет?
Количество строк:
Количество дополнительных объектов:
Масштабируемость:
Скорость выполнения:
Do it raw, fully organic, GMO-free good old way
wait / notify
Классика (: Вводим объект-локер, сохраняем в нем счётчик, по которому будем проверять, все ли Producer-треды выполнились, после чего делаем notify и будим Consumer.
Так как это, считай, тот же самый CountDownLatch, лучше использовать его, т.к. количество строк увеличилось, а пользы от этого больше не стало.
Количество строк:
Количество дополнительных объектов: Зависит от реализации, можно совсем без дополнительных объектов, можно написать свой объект, который будет считать количество выполненных операций (привет, велосипедный CountDownLatch!)
Скорость выполнения: 11-16s
join
Join приостанавливает выполнение одного треда до окончания выполнения другого. Т.к. у нас не один, а целых 5 дополнительных тредов, придётся ввести дополнительный тред, который будет работать, пока они все не отработают. В результате мы вводим дополнительный тред для создания тредов - это несколько портит картину и ухудшает понимание происходящего. Плюс, потокам придётся выполняться последовательно, либо нужно использовать механизм wait / notify. Избыточно, запутанно - не годится.
Количество строк: 10-15
Количество дополнительных объектов: 1-2
Масштабируемость:
Скорость выполнения: 11-16s
Executor
Getting nice and wet with executors
Ого, а вот это огонь! Например, можно использовать fixed size pool, запустить столько потоков, сколько нужно, оповестить Executor о завершении и немного подождать. Главное, не запускать Executor из main-треда, а то он повесится до конца исполнения.
Количество строк: 5-7
Количество дополнительных объектов: 1
Время выполнения: 4-6s
Lock
Very objective! Much synchronized!
Количество строк:
Количество дополнительных объектов:
Время выполнения:
- Для каждого метода засечь время выполнения задачи
- Посчитать количество объектов
- Посчитать количество памяти
- Посмотреть на масштабируемость решения
- Ранжировать результаты по подходящести