Marc Saegesser wrote:
>
> 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.
Not really... for the same reason that a constructor has
problems. The code that returns the true value would get inlined as
a variable assignment... and could possibly be moved somewhere higher
based on dependencies.
I wonder how likely it is that _jspx_init() will be inlined.
-Paul
>
> > -----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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
