OK, if _jspx_init() can be inlined and the _jspx_inited=true assignment
might get interspersed within the inlined code (the fog is lifting now) then
the second approach I presented where the result of _jspx_init() is used
should work.
> -----Original Message-----
> From: Paul Speed [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 26, 2001 2:12 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Thread-safety
>
>
>
>
> Marc Saegesser wrote:
> >
> > 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;
> > }
> > }
> > }
>
> The issue as I understand it is that the constructor might
> have been inlined and then the inlined instructions may have been
> re-ordered. If _jspx_init() can be inlined then it might exhibit
> the same problem. My question is what the spec says about inlining
> virtual methods... I'm pretty sure that _jspx_init() is only a
> candidate for inlining through runtime compilation by Hotspot. But
> I'm not even sure of that.
>
> Otherwise, if it can never be inlined then your original
> assertion is correct.
> -Paul Speed
>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
