одновременное обновление примитивов в Java - PullRequest
0 голосов
/ 14 ноября 2010

Я решаю проблему итеративного вычисления некоторой нижней границы ответа в многопоточной среде.

Во время вычисления может случиться, что число потоков попытается обновить общую переменную примитива.Для меня не имеет значения, кто из них преуспеет в написании своей стоимости, а какой не получится.

Единственная проблема, которая меня беспокоит, заключается в том, возможно ли, что один из потоков записывает часть примитива (например, первые байты), а другой - другую часть (например, последние байты), и в результатезначение этого примитива будет не тем, что потоки пытались написать.

Ссылка на официальную литературу была бы очень признательна.

Заранее спасибо.

Ответы [ 2 ]

4 голосов
/ 14 ноября 2010

Единственная проблема, которая меня беспокоит, заключается в том, возможно ли, чтобы один из потоков записывал часть примитива (например, первые байты), а другой - другую часть (например, последние байты), и в результатезначение этого примитива будет не тем, что потоки пытались записать.

Ссылаясь на Спецификацию языка Java :

Если двойноеПеременная long не объявляется как volatile, поэтому для действий загрузки, сохранения, чтения и записи они обрабатываются так, как если бы они были двумя переменными по 32 бита каждая: если правила требуют одного из этих действий, выполняются два таких действия,по одному на каждую 32-битную половину.Способ, которым 64 бита двойной или длинной переменной кодируются в две 32-битные величины, зависит от реализации.Действия загрузки, сохранения, чтения и записи для энергозависимых переменных являются атомарными, даже если тип переменной является double или long.

Запись в другие примитивы всегда атомарна.Однако, если они не объявлены volatile, обновления могут быть невидимы для других потоков в течение сколь угодно длительного времени.

0 голосов
/ 14 ноября 2010

Классы java.util.concurrent.atomic.Atomic* хорошо решают проблему.Как указывает Майкл, записи в не 64-битные примитивы являются атомарными, но другие потоки могут не видеть новое значение - возможно, когда-либо.

Возможно, вам не нужны устаревшие операции чтения во время вычислений, но нет способа гарантироватьчто поток, который читает окончательное решение, увидит правильное значение, если вы не сделаете примитив энергозависимым, не синхронизируете доступ к нему или не используете AtomicWhatever.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...