Re: Peterson's Algorithm in java, sequencial instruction execution ?
"Mark Thornton" <mark.p.thornton@ntl-spam-world.com> wrote in message
news:wajah.56787$TH3.22896@newsfe2-gui.ntli.net...
Mike Schilling wrote:
"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote in message
news:4569b188$0$631$bed64819@news.gradwell.net...
Mike Schilling wrote:
A third mechanism is provided by the classes in
java.util.concurrent.atomic (from Java 5).
A mechanism not based on one of the first two? What might that be?
Hackery in the JVM implementation, using private internal "magic" (/not/
JNI)
to replace the implementation of those features with custom machine-code
sequences.
Got that, but which features are they? (My customers, and thus me,
aren't using 1.5 yet.)
http://java.sun.com/javase/6/docs/api/java/util/concurrent/atomic/package-summary.html
Which includes the sentence:
The memory effects for accesses and updates of atomics generally follow
the rules for volatiles, as stated in
The Java Language Specification, Third Edition (17.4 Memory Model):
Which is a good thing; having finally updated the memory model into
something sensible, it would be unfortunate to add 1 new set of semantics to
it. Though given that, under JSR 133:
Writing to a volatile field has the same memory effect as a monitor
release, and reading from a volatile
field has the same memory effect as a monitor acquire.
(from the JSR 133 FAQ at
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile)
It's not obvious to me that the use of atomics is substantially more
"efficient" than using synchronization. (Yes, I see lazySet() and
weakCompareAndSet(), but how often would one use them?)