Home

В данном задании необходимо было реализовать блокировку выполнения одного потока, пока не завершится N остальных. В целом, для этой задачи лучше всего подходит CountDownLatch (или Phaser), но почему бы не провести эксперимент?)

Synchronizers

CountDownLatch

Подходит лучше всего, самым первым приходит в голову при выборе подходящего инструмента. CountDownLatch предназначен для блокирования выполнения одного потока пока не будут выполнено определенное количество операций. В нашем случае у нас должно быть выполнено 5 операций, только после выполнения которых должна быть возобновлена работа Consumer’a.

Количество строк: 3

Количество дополнительных объектов: 1 (собственно, CountDownLatch)

Время выполнения: 2-5s

CyclicBarrier

Циклический барьер тоже неплох для реализации данной задачи.

Количество строк:

Количество дополнительных объектов:

Масштабируемость:

Скорость выполнения:

Semaphore

Количество строк:

Количество дополнительных объектов:

Масштабируемость:

Скорость выполнения:

Exchanger

Количество строк:

Количество дополнительных объектов:

Масштабируемость:

Скорость выполнения:

Phaser

Количество строк:

Количество дополнительных объектов:

Масштабируемость:

Скорость выполнения:

System synchronization

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

Software synchronization

Executor

Getting nice and wet with executors

Ого, а вот это огонь! Например, можно использовать fixed size pool, запустить столько потоков, сколько нужно, оповестить Executor о завершении и немного подождать. Главное, не запускать Executor из main-треда, а то он повесится до конца исполнения.

Количество строк: 5-7

Количество дополнительных объектов: 1

Время выполнения: 4-6s

Lock

Very objective! Much synchronized!

Количество строк:

Количество дополнительных объектов:

Время выполнения:

http://zeroturnaround.com/rebellabs/flavors-of-concurrency-in-java-threads-executors-forkjoin-and-actors/

• Для каждого метода засечь время выполнения задачи
• Посчитать количество объектов
• Посчитать количество памяти
• Посмотреть на масштабируемость решения
• Ранжировать результаты по подходящести