[concurrency-interest] RE: Thread safe or not ?

Olivier Dupuy Olivier.Dupuy at pwgsc.gc.ca
Fri Sep 23 09:53:55 EDT 2005


> > > >
> > > >
> > > > -----Original Message-----
> > > > From: concurrency-interest-bounces at cs.oswego.edu
> > > [mailto:concurrency-interest-bounces at cs.oswego.edu]On
> > > Behalf Of Hanson Char
> > > > Sent: Friday, 23 September 2005 3:19 PM
> > > > To: concurrency-interest at altair.cs.oswego.edu
> > > > Subject: [concurrency-interest] Thread safe or not ?
> > > >
> > > > Assuming JDK5, is the following code always thread safe when
> > > SystemParameter.K is concurrently accessed ? If so, is the
> > synchronization
> > > used in the code minimal ? If not, why not ?
> > > >
> > > > Thanks in advance.
> > > >
> > > > Hanson
> > > >
> > > > public class SystemParameter {
> > > > private static volatile SystemParameterBean bean = init();
> > > > public static final long K = bean.getK();
> > > > static {
> > > > bean = null; // hint to GC
> > > > }
> > > > private static SystemParameterBean init() {
> > > > // This part can be replaced by accessing an IoC framework
> > > > // such as Spring to retrieve an externally configured
> > > > // SystemParameterBean instance.
> > > > SystemParameterBean bean = new SystemParameterBean();
> > > > bean.setK(20);
> > > > return bean;
> > > > }
> > > > }
> > > >
> > > > public class SystemParameterBean {
> > > > private long k;
> > > >
> > > > public long getK() {
> > > > return k;
> > > > }
> > > > public void setK(long k) {
> > > > this.k = k;
> > > > }
> > > > }
> > > >

    > these are long values then atomicity of reads/writes does not apply
and you
    > may read a garbage value.
    > >
    > > Hope that helps.
    > >
    > > David Holmes

Hi,

to add my 2 cents.
Outside of the initialization problem and as mentioned by David,
garbage can be retrieved and synchronization seems required on the getter and setter

from chapter 17.7 pp 579 of the Java language specification book
http://java.sun.com/docs/books/jls/download/langspec-3.0.pdf

17.7 Non-atomic Treatment of double and long
Some implementations may find it convenient to divide a single write action
on a 64-bit long or double value into two write actions on adjacent 32 bit values.
For efficiency's sake, this behavior is implementation specific; Java virtual
machines are free to perform writes to long and double values atomically or in two
parts.
For the purposes of the Java programming language memory model, a single
write to a non-volatile long or double value is treated as two separate writes: one
to each 32-bit half. This can result in a situation where a thread sees the first 32
bits of a 64 bit value from one write, and the second 32 bits from another write.
Writes and reads of volatile long and double values are always atomic. Writes to
and reads of references are always atomic, regardless of whether they are implemented
as 32 or 64 bit values.
VM implementors are encouraged to avoid splitting their 64-bit values where
possible. Programmers are encouraged to declare shared 64-bit values as volatile
or synchronize their programs correctly to avoid possible complications.

Thanks / Merci
Olivier DUPUY



More information about the Concurrency-interest mailing list