か
как это отвечает на исходный вопрос?
А как ещё отвечать на абстрактный вопрос? Там несколько условий, одно из них это interferenceи и оно зависит от того, какой тип операций то проводишь над эрреем
Size: a a a
2020 July 04
か
Parallel computing involves dividing a problem into subproblems, solving those problems simultaneously (in parallel, with each subproblem running in a separate thread), and then combining the results of the solutions to the subproblems. Java SE provides the fork/join framework, which enables you to more easily implement parallel computing in your applications.
A
Нет, так как память непонятно когда синхронизируется в таком случае.
http://gee.cs.oswego.edu/dl/cpj/jmm.html
http://gee.cs.oswego.edu/dl/cpj/jmm.html
Почему непонятно? На join должна по идее уже синхронизировать куски массива
After join method returns, all subsequent actions in thread A will see all actions performed in thread B's run method happened before them.
Или по вашей же ссылке:
As a thread terminates, all written variables are flushed to main memory. For example, if one thread synchronizes on the termination of another thread using Thread.join, then it is guaranteed to see the effects made by that thread (see §4.3.2).
А поскольку до join одновременной работы с ячейками нет, что может пойти не так?
After join method returns, all subsequent actions in thread A will see all actions performed in thread B's run method happened before them.
Или по вашей же ссылке:
As a thread terminates, all written variables are flushed to main memory. For example, if one thread synchronizes on the termination of another thread using Thread.join, then it is guaranteed to see the effects made by that thread (see §4.3.2).
А поскольку до join одновременной работы с ячейками нет, что может пойти не так?
QH
Какая разница, кто что куда пишет, если треды пишут в непересекающиеся индексы??
Хммм, я бы не был так уверен, когда элемент массива меньше машинного слова.
A
Хммм, я бы не был так уверен, когда элемент массива меньше машинного слова.
Ну пусть будут у всех свои копии половины слова. Синхронизация разве по словам будет идти потом?
Само решение конечно смотрится опасным, т.к. в случае багов потоки могут залезть в чужую область. И плохо расширяемо, неудобно перераспределять наспойки чанков и количество потоков. Массив так менять, не получится, как в случае с ForkJoinPool, в рантайме пересчитывая размеры чанков от входящей нагрузки и подключать больше потоков. Но видимо решение претендует на производительность. А раз так, думаю имеет право на жизнь, хотя бы до бенча. И если JMM ничего против не имеет, почему не попробовать (сравнив на целевой нагрузке со сборкой массива по кусками из потока ForkJoinPoll)?
Само решение конечно смотрится опасным, т.к. в случае багов потоки могут залезть в чужую область. И плохо расширяемо, неудобно перераспределять наспойки чанков и количество потоков. Массив так менять, не получится, как в случае с ForkJoinPool, в рантайме пересчитывая размеры чанков от входящей нагрузки и подключать больше потоков. Но видимо решение претендует на производительность. А раз так, думаю имеет право на жизнь, хотя бы до бенча. И если JMM ничего против не имеет, почему не попробовать (сравнив на целевой нагрузке со сборкой массива по кусками из потока ForkJoinPoll)?
O
Пилишь таск, фреймворк за тебя разделяет твой сурс на сабтаски (форк), выполняет их, потом делают джоин
меня как раз низкоуровнево волнует, а не как переиспользовать треды - это ясно и так
а вот то что куски массива буду синхронизированы - это неочевидно, я гуглил и не нашел точного ответа
а вот то что куски массива буду синхронизированы - это неочевидно, я гуглил и не нашел точного ответа
A
вопрос как раз конкретный, а вы перевели его на тредпулы зачем то
Синхронизация похоже не требуется, благодаря тому что результат потока happens before join().
Зато возникает производный вопрос - что эффективней сработает: синхронизация массива на join или сборка из отдельных потоков, завершающихся в произвольном порядке.
Зато возникает производный вопрос - что эффективней сработает: синхронизация массива на join или сборка из отдельных потоков, завершающихся в произвольном порядке.
MN
не знаю почему но линейная выполнение иногда быстрее чем forkjoin
MN
идея у него прикольная то что все workers работают даже после выполнение задачи , но зачастую хватает и streams
MN
вот у меня вопрос есть как сделать то чтоб кнопки через Robot зажать? для этого целый поток создавать? или какой то concurrency класс использовать с ограниченными потоками?
AE
Anton
Почему непонятно? На join должна по идее уже синхронизировать куски массива
After join method returns, all subsequent actions in thread A will see all actions performed in thread B's run method happened before them.
Или по вашей же ссылке:
As a thread terminates, all written variables are flushed to main memory. For example, if one thread synchronizes on the termination of another thread using Thread.join, then it is guaranteed to see the effects made by that thread (see §4.3.2).
А поскольку до join одновременной работы с ячейками нет, что может пойти не так?
After join method returns, all subsequent actions in thread A will see all actions performed in thread B's run method happened before them.
Или по вашей же ссылке:
As a thread terminates, all written variables are flushed to main memory. For example, if one thread synchronizes on the termination of another thread using Thread.join, then it is guaranteed to see the effects made by that thread (see §4.3.2).
А поскольку до join одновременной работы с ячейками нет, что может пойти не так?
Например что работаете с ячейками одной переменной, которая будет синхронизироваться с двух потоков
AS
подскажите, безопасно ли будет конкурентно писать разными потоками в непересекающиеся диапазоны в int array?
- например, 1 поток работает с [0,50], второй только с [51,100]
- потом идет join обоих и хочется видеть результат работы в main потоке
или какая синхронизация требуется?
@shipilev не подскажешь?
- например, 1 поток работает с [0,50], второй только с [51,100]
- потом идет join обоих и хочется видеть результат работы в main потоке
или какая синхронизация требуется?
@shipilev не подскажешь?
В этом сценарии никакой не требуется. Разные элементы массива по спеке выступают как независимые локации, поэтому потоки не интерферируют. Thread.join делает видимым всё сделанного в потоке тому, кто заджойнил, т.е. main-потоку.
AS
Может получиться так, что хвосты подмассивов лежат на одной кешлинии, и потоки будут за неё драться, но это проблема производительности, а не корректности.
AE
В этом сценарии никакой не требуется. Разные элементы массива по спеке выступают как независимые локации, поэтому потоки не интерферируют. Thread.join делает видимым всё сделанного в потоке тому, кто заджойнил, т.е. main-потоку.
Т.е. куски массива успешно независимо шарятся между потоками и независимо синкаются?
AS
Т.е. куски массива успешно независимо шарятся между потоками и независимо синкаются?
Сами по себе они ничего не делают, но если с ними что-то происходит, то с разными элементами всё происходит индивидуально. Другими словами, разные элементы массива с точки зрения модели памяти ведут себя так же, как разные поля в одном и том же инстансе, например.
AS
"17.6 Word Tearing
One consideration for implementations of the Java Virtual Machine is that every field and array element is considered distinct; updates to one field or element must not interact with reads or updates of any other field or element. In particular, two
threads that update adjacent elements of a byte array separately must not interfere or interact and do not need synchronization to ensure sequential consistency."
One consideration for implementations of the Java Virtual Machine is that every field and array element is considered distinct; updates to one field or element must not interact with reads or updates of any other field or element. In particular, two
threads that update adjacent elements of a byte array separately must not interfere or interact and do not need synchronization to ensure sequential consistency."