This is a truly fascinating thread of discussion. However, from reading the
article _The "Double-Checked Locking is Broken" Declaration_
(http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)
It seems to me that the following code is thread safe.
if (_jspx_inited == false) {
synchronized (this) {
if (_jspx_inited == false) {
_jspx_init();
_jspx_inited = true;
}
}
}
The case described in the article is the following
class Foo {
private Helper helper = null;
public Helper getHelper() {
if (helper == null)
synchronized(this) {
if (helper == null)
helper = new Helper();
}
return helper;
}
// other functions and members...
}
}
The problem is that helper may be assigned a value before the Helper
constructor executes. Thus another thread may come along and notice a
non-null value for helper and attempt to use un-initialized values.
In the _jspx_inited case above the only requirement is that compiler can't
rewrite the code into the equivalent of
if (_jspx_inited == false) {
synchronized (this) {
if (_jspx_inited == false) {
_jspx_inited = true;
_jspx_init();
}
}
}
Such a re-ordering seems illegal to me (what if jspx_init() uses the value
of _jspx_inited?). If, however, it is legal reordering then the example of
a "correct" double-check mechanism for 32-bit primitive values should work
here. It would look something like
boolean tmpInited = _jspx_inited;
if (tmpInited == false) {
synchronized (this) {
if (tmpInited == false) {
tmpInited = _jspx_init(); // NOTE: _jspx_init() needs to
return true
_jspx_inited = tmpInited;
}
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
