Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-Id: <5.0.2.1.2.20010126181140.025b3ba0@pop.quiotix.com>
Date: Fri, 26 Jan 2001 18:15:44 -0800
To: tomcat-dev@jakarta.apache.org
From: Brian Goetz <brian@quiotix.com>
Subject: Re: Thread-safety
Cc: rubys@us.ibm.com
In-Reply-To: <OF0EBAD806.0D0A0B41-ON852569E1.000ACE43@raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed


>The reputation of Bill Pugh is quite high - enough so that I would be
>nclined to take his statements on this subject as beyond challenge.

As well you should.  And many very smart people have signed his 
declaration, including Doug Lea.

>Upon careful reading of the link mentioned in this thread, I came across
>the following:
>
>    It will work for 32-bit primitive values
>
>    Although the double-checked locking idiom cannot be used for references
>    to objects, it can work for 32-bit primitive values (e.g., int's or
>    float's). Note that it does not work for long's or double's, since
>    unsynchronized reads/writes of 64-bit primitives are not guaranteed to
>    be atomic.

This statement is true, but very easy to misinterpret; be careful.  There 
have been many attempts to "fix" DCL by trying to exploit that; they all 
fail.

>Based on this, it would seem to me that the code snippet staring with "if
>(_jspx_inited == false) {" is safe.  Worst case, change _jspx_inited from
>boolean to int.

Seems that way, but its not.  You can't use this to make an end-run around 
the problem in the general case.  If jspx_init() creates any objects, 
you've gotta synchronize, plain and simple.  If jspx_init() calculates 
multiple primitive values, which can obtained through any other means than 
its return value, you've gotta synchronize.


--
Brian Goetz
Quiotix Corporation
brian@quiotix.com           Tel: 650-843-1300            Fax: 650-324-8032

http://www.quiotix.com