Date: Tue, 6 Jul 1999 08:50:02 -0400
From: Bill Pugh <pugh@cs.umd.edu>
At 2:01 PM +0000 7/5/99, David G. Wonnacott wrote:
>
> ...
>
>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.
The idea that Josh and I talked about, and is discussed in the
"getting the ball rolling" msg, is that there should be some
synchronization idiom that allows this semantics. Constructors would
offer this semantics without the need to use a special
synchronization idiom.
At 11:18 AM -0400 6/24/99, Bill Pugh wrote:
> - 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.
>From the point of view of concise language definition and simpler
implementation, providing this idiom via the constructor is clearly
attractive (as you noted, it avoids the need to create a special
synchronization idiom).
However, simplicity of language design and simplicity of use do not
always coincide. IMHO, this is often the case when a single language
feature is given two tasks that are not fundamentally related. The
question is: are "creating an object" and "making an object ready for
publication" two tasks or one? If the Java language uses constructors
as the only mechanism to support the "initialize-and-publish" idiom,
then it forces programmers to work with creation and preparation for
publication as one task. I don't know enough about this idiom to
decide whether this is a very good thing or a very bad thing. Perhaps
someone more familiar with the use of this idiom could comment?
Bill Pugh's response to Sarita's comments (the message of Sun, 4 Jul
1999 17:37, #0080 in the archive), discusses the possibility of having
an alternate approach:
However, there should be a way to make it work, in case we don't have
an appropriate constructor. Perhaps:
void setPos(int x, int y) {
Point tmp;
synchronized (tmp = new Point()) {
tmp.x = x; tmp.y = y;
}
p = tmp;
}
I thought we should consider the impact on the way programmers can use
the "initialize-then-publish" idiom in any decision to include or
exclude this option.
Dave W
-------------------------------
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:16 EDT