First, an introduction -- I'm one of Bill Pugh's first Ph.D. students,
and now on the faculty at Haverford College. I don't have much
background with Java, and have been "lurking" on this list because I
thought the topic sounded interesting when Bill mentioned it to me
some time ago.
I've recently been looking at ways in which object-oriented languages
reserve certain powers for class authors, and it occurred to me that
this issue may come up in the "safe, unsynchronized reads" thread on
this list. So I'll de-lurk to respond to
Date: Sun, 4 Jul 1999 17:37:19 -0400
From: Bill Pugh <pugh@cs.umd.edu>
> Do extra ordering
>guarantees apply only for writes inside constructors or whether they
>extend to all writes that occur prior to publishing?
For initialization safety, the guarantee would be that all writes
performed by the thread between the time the constructor was started
until the time the constructor completes normally are made visible to
all processors before any reference to that object, written after
completion of the constructor, becomes visible.
Giving guarantees for writes that occur "inside constructors" rather
than "prior to publishing" seems to require that the author of a class
anticipate what sort of safe unsynchronized reads are going to be
needed when the class is used (since users of the class can't add
constructors to it). It might be worth weighing this factor when
making a choice between the two approaches.
In general terms, sometimes it is beneficial (from a software design
point of view) to place some responsibilities on the class author --
i.e. data encapsulation makes the class author responsible for all
access to implementation data (and thus gives the author control of
that data); in other cases, unnecessary responsibilities force a class
author to commit to things that they cannot always predict (some would
argue that C++'s use of the keyword "virtual" to enable dynamic
dispatch is such a case). My question is: In which category do we
place decisions about safe unsynchronized reads?
Specifically, suppose we want to allow safe access to an object of
type X, which contains a datum of type Y, and we need to ensure that
the Y has property y when the X is "published". If there's an X
constructor that established property y, then we can use that
constructor; If there's an X constructor that takes a Y, and a Y
constructor that establishes y, then we can create the proper Y and
use it to initialize the X.
On the other hand, if the authors of X and Y have not provided
constructors to establish y, we might try to achieve our goal by
creating a Y, using a method to establish property y, and then
initializing the X with the resulting value. If the language
only makes guarantees about writes in constructors, then this is not
safe (even though the X constructor saves the reference to the Y, the
writes done inside the Y method may not be visible in the other
thread).
We could work around this by creating another class and putting the
entire "create a Y / establish y / create an X" sequence in the
constructor for the class. In fact, you could probably allow any
arbitrary setup to occur in this way. But making a new class just for
the purpose of synchronizing one set of writes seems quite ugly to me.
Unfortunately, if the language makes a guarantee that all writes that
affect the X will be visible when we publish the X, the system will
have to figure out that the call that establishes y affects the X. It
seems to me that this could be prohibitively expensive.
I apologize if the text above is less clear than a sample Java
program, but I don't have my Java books with me today, and I don't
know Java well enough to get the syntax right without a reference, and
I assume that incorrect Java could be even more vague than English.
Dave Wonnacott
davew@cs.haverford.edu
http://www.haverford.edu/cmsc/davew/index.html
-------------------------------
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:15 EDT