> I just started following the issues related to the JMM at Bill's
>site. I think that the problems with the JMM are very bad and their
>resolve is very important to the advancement of Java. I am currently
>building a JDBC connection pool implementation. It is complex in terms
>of its multithreaded nature. There are a few techniques I am using to
> double-check idiom
> copy on write
> no sync on read, sync on write --flags (ints/booleans used for state)
Looking at this again, I decided I wanted to make a specific warning
against using no sync on read, sync on write for flags, even if it may
seem obvious. If you have code like:
//flag starts out true
// do something not involving flag.
flag = false;
there is no guarantee that the update to flag will *ever* be seen by the
first thread. A perfectly reasonable compiler optimization will hoist
the read of flag out of the loop in the first thread, under the
assumption that flag will never be changed.
You can't get around this by putting the read of flag in a function,
either, because functions can be inlined and then optimized.
The point is, again, that you have to be *really* careful about such
things, and use provided structures like Thread.interrupt() and
wait()/notify() when you can.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:27 EDT