If you treat a possible exception as basically a conditional branch
(modulo a bunch of differences that don't matter to the memory model unless
you're more precise about intra-thread consistency then we've all been),
you get the right answer.
For example, the behavior in 6Ex is clearly disallowed if comp() returns
null, since there is no race in a sequentially consistent execution. I
think the same applies to 6Ex1.
Synchronous exceptions are just intra-thread control flow. I believe
sophisticated compilers generally add the corresponding control-flow edges
Asynchronous exceptions (something like Posix signals) would be a
different matter, if they really existed in Java.
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org]On Behalf Of Vijay Saraswat
> Sent: Friday, April 09, 2004 11:17 AM
> To: Bill Pugh
> Cc: javamemorymodel-cs.umd.edu
> Subject: Re: JavaMemoryModel: Interaction between the memory model and
> I dont know what to make of this. Maybe you can tell me how the test
> cases I sent out in a subsequent message are intended to be
> handled and why.
> Bill Pugh wrote:
> > This pretty much falls out of the rules for unithread semantics.
> > Exceptions aren't really treated
> > any different from any other form of control flow.
> JavaMemoryModel mailing list -
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:03 EDT