At 02:10 PM 19/01/2004 -0500, Bill Pugh wrote:
>Part of the problem comes from a lack of any formal definition of what
>"leak" means, or what occurs in the "Do stuff with d" section. Assume we
>prove that the "Do stuff with d" section cannot possibly write the value
>contained in d out to the heap. Then, you show:
>* the method doWork has only one place where it stores a reference
> to a Delegate (when it allocates a new internal delegate, and stores
> it to internalDelegate).
>* the method doWork does not return a reference to an internal Delegate nor
> store it to any location other than internalDelegate.
>* No other method reads the value of internalDelegate.
Yes, and essentially this reasoning is what I used when I convinced myself
that the class is safe. I note, though, that this line of reasoning does
not take into account the order in which things occur, nor does it involve
mutual exclusion arguments. I feel that reasoning of this nature represents
the limit of what developers will be willing to use when showing that their
code is safe from multi-threaded attack.
Such a line of reasoning to my mind falls more naturally out of SC- than
out of M/P, if only because the latter model provides additional guarantees
that muddy the water.
Those additional guarantees have a potential cost in terms of lost
optimisations. I am far from clear as to where the corresponding benefit lies.
I have obviously come done on the side of SC-, at least for the time being.
I wish other disinterested parties - ie, not the creators of the models,
would express some views.
Sylvia.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:56 EDT