> Provide a synchronization idiom that provides a safe way for a thread
> to construct an object, perform a series of updates on the object,
> and then publish the object (store a reference to the object in memory
> read by other threads). Other threads should then be able to read that
> reference and see an object that reflects all of the modifications.
I cannot see how this can be implemented efficiently. The discussion so
far has focused on putting memory barriers on the writer's side (the writer
being the thread initializing and object). However, correct
synchronization requires memory barriers by both the writer _and_ the
readers (the readers being the "other threads" that, according to the quote
above, "should be able to read that reference and see an object that
reflects all of the modifications"). How can reader-side barriers be put
in place efficiently?
The above paragraph is from the implementor's perspective. Let's look at
it from the programmer's perspective.
Here at SRC (the Systems Research Center, down the street from the Western
Research Center), we've been programming with threads on multiprocessor
systems for many years, in the context of Modula-3, in the context of
C/pthreads, and, more recently, in the context of Java. It is common
knowledge that the idiom being proposed here -- publishing a read-only
object and allowing synchronization-free reads -- does not work.
Programming without this idiom has not been a significant problem.
Based on this analysis, it seems to me that this idiom should _not_ be
viewed as a requirement for the specification.
Regards,
Raymie Stata
P.S. The above discussion does _not_ apply to "preserving safety
guarantees" (which involves atomically initializing newly-allocated objects
to zero). Nor does it apply to read-only objects published through
_final_, _static_ fields of classes. There are reasonable implementations
of both of these features, and they _are_ important from a programmer's
perspective. But when it comes to read-only access to objects published
through non-static fields or non-final, static fields, synchronization does
not represent a burden and should be required.
-------------------------------
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email majordomo@cs.umd.edu and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:12 EDT