At 11:31 AM 19/01/2004, David Holmes wrote:
>I don't quite understand the point you are trying to make here. The
>first version of the code has a property that only holds if the
>non-threadsafe code is not used in a non-threadsafe manner.
>Intuitively the lack of synchronization allows a thread to potentially
>see any value that had been stored as the delegate - including the
>internally defined one.
A memory model simpler than SC- and M/P could just say that if you write
programs containing data races, then all bets are off as to what it will
do. The message would be to make sure that your programs are correctly
synchronized.
I don't believe this intricate discussion about memory models is really
about letting 0.1% of the world's programmers come up with devious code
that is correct despite containing data races.
From my perspective, the main reason the simpler model is not acceptable
is that developers can quite innocently write a class that is not intended
to be used in a multi-threaded way, but which exposes security holes when
malicious code invokes the methods from multiple threads.
Faced with this, the developer has to have some awareness of the
ramifications of multi-threaded accesss when writing code that has security
implications. Dealing with these ramifications should not involve
synchronizing everything in sight. Instead, the developer needs an
understandable model the allows a determination of whether a piece of code
would be safe when abused in a multi-threaded context.
As you say, my first 'solution' is clearly wrong. I believe the second
solution is correct under both SC- and M/P, but I'm having some trouble
coming up with a form of words that justifies my belief under M/P. It seems
to involve the assertion that for it to be incorrect there would have to be
a permitted out-of-thin-air value regardless of any justification order and
forbidden execution sets.
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