Comments on: Модель памяти Java и атомарность операций (java memory model) http://www.javenue.info/post/81 Блог разработчика о Java и родственных технологиях Thu, 09 Sep 2010 00:09:55 +0000 http://wordpress.org/?v=2.2.1 By: artemv http://www.javenue.info/post/81#comment-63844 artemv Sun, 17 Jan 2010 18:19:23 +0000 http://www.javenue.info/post/81#comment-63844 @c0nst <i>Ключевое слово volatile говорит (в частности интерпретатору байт-кода) о том, что не нужно использовать регистровые оптимизации для этой переменной.</i> да, но_ так было и в 1.3, и в 1.4. ? только в 1.5 JMM даёт гарантию что volatile не будет "reorder-иться" с другими переменными на "multithread-овых" участках. <code> class A { private int i; private volatile j; void a() { i=1; j=2; } } </code> JMM-ское правило относительно volatile гарантирует что i выполнится перед j в любом thread-е. @c0nst
Ключевое слово volatile говорит (в частности интерпретатору байт-кода) о том, что не нужно использовать регистровые оптимизации для этой переменной.
да, но_ так было и в 1.3, и в 1.4. ? только в 1.5 JMM даёт гарантию что volatile не будет “reorder-иться” с другими переменными на “multithread-овых” участках.

class A {
private int i;
private volatile j;
void a() {
i=1;
j=2;
}
}

JMM-ское правило относительно volatile гарантирует что i выполнится перед j в любом thread-е.

]]> By: Эндрю http://www.javenue.info/post/81#comment-57898 Эндрю Fri, 07 Aug 2009 10:14:05 +0000 http://www.javenue.info/post/81#comment-57898 На http://java.sun.com/docs/books/tutorial/essential/concurrency/atomic.html есть такие строчки " * Reads and writes are atomic for reference variables and for most primitive variables (all types except long and double). * Reads and writes are atomic for all variables declared volatile (including long and double variables). " - volatile для типа int не нужен, хотя, от него и хуже наверное не будет. А использование обёртки java.util.concurrent.atomic.AtomicInteger, как заметил Vladimir Dolzhenko, быда бы кстати. Но цель автора была, на сколько я понял, показать неатомарность операций "--" и "++", поэтому и synchronized подойдёт :-) На http://java.sun.com/docs/books/tutorial/essential/concurrency/atomic.html есть такие строчки
”
* Reads and writes are atomic for reference variables and for most primitive variables (all types except long and double).
* Reads and writes are atomic for all variables declared volatile (including long and double variables).
”
- volatile для типа int не нужен, хотя, от него и хуже наверное не будет.
А использование обёртки java.util.concurrent.atomic.AtomicInteger, как заметил Vladimir Dolzhenko, быда бы кстати.
Но цель автора была, на сколько я понял, показать неатомарность операций “–” и “++”, поэтому и synchronized подойдёт :-)

]]> By: Leon http://www.javenue.info/post/81#comment-37259 Leon Fri, 19 Dec 2008 11:42:47 +0000 http://www.javenue.info/post/81#comment-37259 Да, согласен, не обратил внимания на характер b. Да, согласен, не обратил внимания на характер b.

]]> By: c0nst http://www.javenue.info/post/81#comment-37239 c0nst Fri, 19 Dec 2008 10:20:40 +0000 http://www.javenue.info/post/81#comment-37239 Да, спасибо, забыл volatile поставить, чтобы гарантировать, что все потоки будут видеть одно и то же значение переменной i. Здесь имеет место понятие видимость (Visibility). Ключевое слово volatile говорит (в частности интерпретатору байт-кода) о том, что не нужно использовать регистровые оптимизации для этой переменной. Да, спасибо, забыл volatile поставить, чтобы гарантировать, что все потоки будут видеть одно и то же значение переменной i. Здесь имеет место понятие видимость (Visibility).
Ключевое слово volatile говорит (в частности интерпретатору байт-кода) о том, что не нужно использовать регистровые оптимизации для этой переменной.

]]> By: Vladimir Dolzhenko http://www.javenue.info/post/81#comment-37229 Vladimir Dolzhenko Fri, 19 Dec 2008 08:49:06 +0000 http://www.javenue.info/post/81#comment-37229 в приведённом примере вообще не гарантируется, что значение свойства i будет в потоке 2 будет такое же, какое оно будет записано в потоке 1. Опять же согласно Java Memory Model. Чтобы избежать этот нюанс св-во i должно иметь модификатор volatile, но даже это не ре?ит вопрос атомарности инкремента/дикремента синхронизация через synchronized для соблюдения атомарности подобных операций - overhead, не мало обзоров на тему производительности - чтобы не потерять производительность, и в то же время иметь атомарность операций примитивов есть атомарные классы обёртки, н-р. java.util.concurrent.atomic.AtomicInteger. в приведённом примере вообще не гарантируется, что значение свойства i будет в потоке 2 будет такое же, какое оно будет записано в потоке 1. Опять же согласно Java Memory Model. Чтобы избежать этот нюанс св-во i должно иметь модификатор volatile, но даже это не ре?ит вопрос атомарности инкремента/дикремента

синхронизация через synchronized для соблюдения атомарности подобных операций - overhead, не мало обзоров на тему производительности - чтобы не потерять производительность, и в то же время иметь атомарность операций примитивов есть атомарные классы обёртки, н-р. java.util.concurrent.atomic.AtomicInteger.

]]> By: c0nst http://www.javenue.info/post/81#comment-37217 c0nst Fri, 19 Dec 2008 08:15:04 +0000 http://www.javenue.info/post/81#comment-37217 Атаморность поля b не имеет смысла в данном контексте, так как это поле экземпляра класса и у каждого потока есть свое собственное значение этого поля. Как раз Java и не гарантирует атомрность инкремента, что собственно и показывает данный пример. Атаморность поля b не имеет смысла в данном контексте, так как это поле экземпляра класса и у каждого потока есть свое собственное значение этого поля.
Как раз Java и не гарантирует атомрность инкремента, что собственно и показывает данный пример.

]]> By: Leon http://www.javenue.info/post/81#comment-37159 Leon Fri, 19 Dec 2008 03:40:39 +0000 http://www.javenue.info/post/81#comment-37159 А разве этот пример доказывает неатомарность операции инкремента, ведь в программном фрагменте присутствует еще и условный переход? Это я к тому написал, что, понятно, в ма?инном коде операция инкремента будет состоять из нескольких инструкций, но насколько я помню джава все-таки гарантирует атомарность таких операций. А разве этот пример доказывает неатомарность операции инкремента, ведь в программном фрагменте присутствует еще и условный переход? Это я к тому написал, что, понятно, в ма?инном коде операция инкремента будет состоять из нескольких инструкций, но насколько я помню джава все-таки гарантирует атомарность таких операций.

]]>