public class Atomicity extends Thread {
private int value;
/*volatile*/ static long i;
public void run() {
while (true) {
i = value;
}
}
public static void main(String[] args) {
new Atomicity(1).start();
new Atomicity(-1).start();
while (true)
{
long icopy = i;
if (Math.abs(icopy) != 1)
System.out.println(icopy);
}
}
public Atomicity(int value)
{
super();
this.value = value;
}
}
Атомарность??
Подскажите, что значит атомарная - операция?
я правильно понимаю что в жаве, атомарна, только операция присваивания(=)? Ну имеется в виду среди тех операций которые влекут изменение операнда..
Судя по спецификации JVM операции load/store/read/write над double или long в общем случае не атомарны.
1. Почитайте про слово volatile
2. Почитайте статью http://www.javenue.info/post/81 и поймите что volatile не панацея и не может заменить собой синхронизацию
3. Чтобы всетаки понять зачем нужно volatile поекспериментируйте с моим примером.
PS/ не уверен будет ли мой пример показательным на 64-битной оси.
2. Почитайте статью http://www.javenue.info/post/81 и поймите что volatile не панацея и не может заменить собой синхронизацию
3. Чтобы всетаки понять зачем нужно volatile поекспериментируйте с моим примером.
Код:
PS/ не уверен будет ли мой пример показательным на 64-битной оси.
Цитата: Rebbit
1. Почитайте про слово volatile
А каким боком volatile относится к атомарности?
Он ведь нужен для сквозного чтения/записи значений ("мимо регистров") в многопроцессорных системах.
Цитата: hardcase
А каким боком volatile относится к атомарности?
Вы запускали модифицырованый мной пример?
Цитата: Rebbit
Вы запускали модифицырованый мной пример?
У меня нет Java-компилятора.
Цитата: hardcase
У меня нет Java-компилятора.
Без volatile у вас может случится что в определенный момент времени 32 бита будет от одного присваивания, а вторая половина от другого.
У меня выводятся в консоль числа 4294967295 (старшие розряды от 1,а младшые от -1)
и наоборот число -4294967295
Если добавить volatile то поле будет присваиватся и читатся атомарно. И в консоль вообще ничего не выведется. Так как в і будет либо 1 либо -1
В примере из статьи volatile не помагает, потому что -- и ++ не атомарные.
На сколько я понимаю, они розкладаются в чтото типа bufer = i; i = bufer+1;
тоесть чтение и запись в i всеровно будут атомарными, а вот на bufer и произойдет розезд значений.
К примеру 2 трида будут вместе делать инкремент при і=0, а в результате присвоится не 2, а только 1.
Хардкейз прав. volatile конструкция полезная, но к атомарности отношения не имеет. )
Цитата: Rebbit
Без volatile у вас может случится что в определенный момент времени 32 бита будет от одного присваивания, а вторая половина от другого.
Это будет из-за отсутствия синхронизации доступа к i, а вовсе не из-за отсутствия volatile.
Цитата: Rebbit
Вы запускали модифицырованый мной пример?
Нет, а зачем? Мне достаточно посмотреть на него. Там не сотни строк кода.
Цитата: aks
Нет, а зачем? Мне достаточно посмотреть на него. Там не сотни строк кода.
Ну хорошо. Вот вам сотни строк, хоть кода там не так уж и много.
http://fuseyism.com/classpath/doc/java/util/concurrent/atomic/AtomicLong-source.html
Обратите внимание каким именно образом реализована атомарность.
Насколько я умею читать то для гет и сет достаточно модификатора volatile
Более сложные операцыи наблюдаем только на конструкцыях типа (читать-модифицыровать-присвоить)
Цитата: hardcase
У меня нет Java-компилятора.
Для храбрых душой :). Пока бекдоров не замечено
Цитата: aks
Хардкейз прав. volatile конструкция полезная, но к атомарности отношения не имеет. )
Появление volatile действительно кажется странным, но это так:
[QUOTE=JVM Spec]
8.4 Nonatomic Treatment of double and long Variables
If a double or long variable is not declared volatile, then for the purposes of load, store, read, and write operations it is treated as if it were two variables of 32 bits each; wherever the rules require one of these operations, two such operations are performed, one for each 32-bit half. The manner in which the 64 bits of a double or long variable are encoded into two 32-bit quantities and the order of the operations on the halves of the variables are not defined by The Java Language Specification.
[/QUOTE]
и тут же
[QUOTE=JVM Spec]
An implementation is free to implement load, store, read, and write operations for double and long values as atomic 64-bit operations; in fact, this is strongly encouraged.
[/QUOTE]
тоесть пример может работать здесь и не работать тут
Вот с этим полностю согласен. :)
На практике оно вроде и роботает, а на другой виртуалке может и поломаться.
На практике оно вроде и роботает, а на другой виртуалке может и поломаться.
Дык это только опять же показывает, что присваивание некэшируемой переменной - может быть атомарным. А может и не быть. Это скорее хак, и связывать volatile с атомарностью все же некорректно. Оно для другого предназначено.
Кстати в приведенном реббитом коде как раз таки вызываются unsafe конструкции, использующие судя по всему аппаратные атомарные операции типа сравнения с заменой и т.п.
Если уж хочется работать с атомарными операциями - уж лучше пользоваться тем классом на мой взгляд чем хаками. )
Кстати в приведенном реббитом коде как раз таки вызываются unsafe конструкции, использующие судя по всему аппаратные атомарные операции типа сравнения с заменой и т.п.
Если уж хочется работать с атомарными операциями - уж лучше пользоваться тем классом на мой взгляд чем хаками. )
Цитата: aks
Это скорее хак, и связывать volatile с атомарностью все же некорректно. Оно для другого предназначено.
Вы правы. Но тем не менее Sun связали и задокументировали.
http://download.oracle.com/javase/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).
Атомарность обычно обсуждается в контексте lock-free / wait-free алгоритмов и атомарных примитивов их пакета java.util.concurrent.*, которые используют CAS-инструкции и Java Unsafe API для доступа к ним.
а как сборщик ведет себя с volatile - переменными?
А должен вести как то по особому?
ну я так понимаю, что сборщик почищает все ресурсы потока - после его завершения, чего не происходит с volatile - ресурсами.. Из чего напрашивается вывод что они почищаются после завершения потока общего прородителя? Если так, то вероятность утечки памяти очень велика, или я чето не правильно понимаю??
А что ты имеешь ввиду под подчищением ресурсов потока? Разве сборщик не удаляет ресурсы после того как на них нету ссылок? Не важно из потоков или нет. volatile всего лишь запрещает кэшировать результат. Как это должно помешать сборщику мусора?
Так в том-то и дело что сборщик удаляет ресурсы на которые нет ссылок, но в случае с volatile - этого не происходит..
public class Atomicity extends Thread {
volatile static int i=0;
boolean b;
Atomicity(boolean b) {
this.b = b;
}
public void run() {
if(b) i++;
System.out.println(i);
}
public static void main(String[] args) {
new Atomicity(true).start();
System.gc();
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
new Atomicity(false).start();
}
}
Выводит 1 1
public class Atomicity extends Thread {
volatile static int i=0;
boolean b;
Atomicity(boolean b) {
this.b = b;
}
public void run() {
if(b) i++;
System.out.println(i);
}
public static void main(String[] args) {
new Atomicity(true).start();
System.gc();
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
new Atomicity(false).start();
}
}
Выводит 1 1
Цитата: bnm
Так в том-то и дело что сборщик удаляет ресурсы на которые нет ссылок, но в случае с volatile - этого не происходит..
Для начала нужно понимать, что сборщик мусора не собирает int'ы ;) ЕМНИП объект потока связан с потоком, который выполняется, так что ссылка на него продолжает существовать.
что значит ЕМНИП объект? изменил на Integer, тоже самое...
эм... а я пример не понял при чём тут сборщик? переменная статическая - кто её куда соберёт здесь?
[QUOTE=<SCORP>;354191]эм... а я пример не понял при чём тут сборщик? переменная статическая - кто её куда соберёт здесь?[/QUOTE]
Ну и что, что статическая? Мне не понятно следующее: создается экземпляр Atomacity, значение i = 0, изменяем его на 1, убиваем этот экземпляр, создаем новый - По идее у него i должно равняться 0 но оно равняется 1
Ну и что, что статическая? Мне не понятно следующее: создается экземпляр Atomacity, значение i = 0, изменяем его на 1, убиваем этот экземпляр, создаем новый - По идее у него i должно равняться 0 но оно равняется 1
=) Вы точно знаете что такое статическая переменная?