История изменений
Исправление user_id_68054, (текущая версия) :
где пруфы? ссылку, сестра
вот ссылка — http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html ..
вокруг этой статьи — уйма теоретиков уже написало тонны статей :-) в своих блогах...
вот эта самая фраза, показывающая суть мутной спецификации:
When run on a system using the Symantec JIT, it doesn't work. In particular, the Symantec JIT compiles
singletons[i].reference = new Singleton();
to the following (note that the Symantec JIT using a handle-based object allocation system).
0206106A mov eax,0F97E78h
0206106F call 01F6B210 ; allocate space for
; Singleton, return result in eax
02061074 mov dword ptr [ebp],eax ; EBP is &singletons[i].reference
; store the unconstructed object here.
02061077 mov ecx,dword ptr [eax] ; dereference the handle to
; get the raw pointer
02061079 mov dword ptr [ecx],100h ; Next 4 lines are
0206107F mov dword ptr [ecx+4],200h ; Singleton's inlined constructor
02061086 mov dword ptr [ecx+8],400h
0206108D mov dword ptr [ecx+0Ch],0F84030h
As you can see, the assignment to singletons[i].reference is performed before the constructor for Singleton is called. This is completely legal under the existing Java memory model, and also legal in C and C++ (since neither of them have a memory model).
вплодь до сегодняшнего года [не смотря на то что уже кучу лет прошло] — вновь и вновь эту фразу пофторяют хабрамакаки...
и какого-либо работающего (на сегодняшний день) доказательства — разумеется в интернетах не существует :-)
Исправление user_id_68054, :
где пруфы? ссылку, сестра
вот ссылка — http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html ..
вокруг этой статьи — уйма теоретиков уже написало тонны статей :-) в своих блогах...
вот эта самая фраза, показывающая суть мутной спецификации:
to the following (note that the Symantec JIT using a handle-based object allocation system).
0206106A mov eax,0F97E78h
0206106F call 01F6B210 ; allocate space for
; Singleton, return result in eax
02061074 mov dword ptr [ebp],eax ; EBP is &singletons[i].reference
; store the unconstructed object here.
02061077 mov ecx,dword ptr [eax] ; dereference the handle to
; get the raw pointer
02061079 mov dword ptr [ecx],100h ; Next 4 lines are
0206107F mov dword ptr [ecx+4],200h ; Singleton's inlined constructor
02061086 mov dword ptr [ecx+8],400h
0206108D mov dword ptr [ecx+0Ch],0F84030h
As you can see, the assignment to singletons[i].reference is performed before the constructor for Singleton is called. This is completely legal under the existing Java memory model, and also legal in C and C++ (since neither of them have a memory model).
вплодь до сегодняшнего года [не смотря на то что уже кучу лет прошло] — вновь и вновь эту фразу пофторяют хабрамакаки...
и какого-либо работающего (на сегодняшний день) доказательства — разумеется в интернетах не существует :-)
Исправление user_id_68054, :
где пруфы? ссылку, сестра
вот ссылка — http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html ..
вокруг этой статьи — уйма теоретиков уже написало тонны статей :-) в своих блогах...
вот эта самая фраза, показывающая суть мутной спецификации:
to the following (note that the Symantec JIT using a handle-based object allocation system).
0206106A mov eax,0F97E78h
0206106F call 01F6B210 ; allocate space for
; Singleton, return result in eax
02061074 mov dword ptr [ebp],eax ; EBP is &singletons[i].reference
; store the unconstructed object here.
02061077 mov ecx,dword ptr [eax] ; dereference the handle to
; get the raw pointer
02061079 mov dword ptr [ecx],100h ; Next 4 lines are
0206107F mov dword ptr [ecx+4],200h ; Singleton's inlined constructor
02061086 mov dword ptr [ecx+8],400h
0206108D mov dword ptr [ecx+0Ch],0F84030h
As you can see, the assignment to singletons[i].reference is performed before the constructor for Singleton is called. This is completely legal under the existing Java memory model, and also legal in C and C++ (since neither of them have a memory model).
вплодь до сегодняшнего года — вновь и вновь эту фразу пофторяют хабрамакаки...
и какого-либо работающего (на сегодняшний день) доказательства — разумеется в интернетах не существует :-)
Исправление user_id_68054, :
где пруфы? ссылку, сестра
вот ссылка — http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html ..
вокруг этой статьи — уйма теоретиков уже написало тонны статей :-) в своих блогах...
какого-либо работающего (на сегодняшний день) доказательства — разумеется в интернетах не существует
вот эта самая фраза, показывающая суть мутной спецификации:
to the following (note that the Symantec JIT using a handle-based object allocation system).
0206106A mov eax,0F97E78h
0206106F call 01F6B210 ; allocate space for
; Singleton, return result in eax
02061074 mov dword ptr [ebp],eax ; EBP is &singletons[i].reference
; store the unconstructed object here.
02061077 mov ecx,dword ptr [eax] ; dereference the handle to
; get the raw pointer
02061079 mov dword ptr [ecx],100h ; Next 4 lines are
0206107F mov dword ptr [ecx+4],200h ; Singleton's inlined constructor
02061086 mov dword ptr [ecx+8],400h
0206108D mov dword ptr [ecx+0Ch],0F84030h
As you can see, the assignment to singletons[i].reference is performed before the constructor for Singleton is called. This is completely legal under the existing Java memory model, and also legal in C and C++ (since neither of them have a memory model).
Исходная версия user_id_68054, :
где пруфы? ссылку, сестра
вот ссылка — http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html ..
вокруг этой статьи — уйма теоретиков уже написало тонны статей :-) в своих блогах...
какого-либо работающего (на сегодняшний день) доказательства — разумеется в интернетах не существует