Re: Remove data race in libgcj interpreter

[Andrew Haley <aph at redhat dot com>]

Hans Boehm wrote:
> 
> 
> On Fri, 5 Sep 2008, Andrew Haley wrote:
> 
>> You're right, I was assuming exactly that.  OK, but that is presumably
>> simply a lack of volatility in the declaration of PC.
> As a practical matter, that would probably help at the expense
> of slowing things down a bit on some architectures.  Officially this
> doesn't help much, since I believe Posix allows undefined behavior
> for data races, even if they involve volatiles.  Even in terms of
> current implementations, I don't believe it prevents hardware reordering
> on architectures like PowerPC.
> 
> The C++ working paper provides atomic operations to address these
> issues. I think they're even somewhat implemented in the gcc trunk.  But
> I'm not sure you can avoid operations that generate fences on some
> architectures in what should be the fast path.

Indeed.  The solution of detecting the case where two threads are concurrently
executing a method seems far the best: it's obviously correct without requiring
deep analysis of memory behaviour.  I'm investigating that.

Andrew.