Re: JavaMemoryModel: Data races should not be the buffer overflow of the 21st century

From: Jerry Schwarz (
Date: Mon Jul 28 2003 - 15:28:06 EDT

At 09:30 AM 7/28/2003, Bill Pugh wrote:

At 2:00 PM -0700 7/25/03, Jerry Schwarz wrote:
Personally, I always thought the no out of thin air requirement was unreasonable. Among other things it constrains optimizers in ways that have nothing to do with threading and synchronization.  That is, I've always taken the goal to be to allow the optimizer to treat straight line code without any thread related operation (however that is defined) as if no threading were present.  But consider

Thread 1
 c = ...
 x = 3 * c - 1

Thread 2
 y = x

The not out of thin air requirement says that the compiler can't transform Thread 1 to

c = ...
 x = 3 * c

 x = x - 1

  You seem to be suggesting a model where any incorrectly synchronized read can return absolutely any value, with no constraints from the memory model.

I would not object to such a model.  Clear rules as to what could be returned would also be ok.  The problem I have with the causality approach is that it doesn't provide clear rules. You have to follow a long twisty argument to determine what is allowed. And programmers just won't be able to do that reasoning reliably.

  I think this is a really bad idea.

  Data races should not become the buffer overflow of the 21st century. The biggest problem with buffer overflows is that they allow completely arbitrary behavior. Data races in Java programs are going to be at least as common as buffer overflows in C code. Data races should not allow arbitrary values to be returned.

I have this argument with our security people a lot who are always trying to convince me that Java can have "buffer overflow" problems. The problem with buffer overflows in C is not only that arbitrary behavior occurs after the overflow, it is that the external inputs can cause specific behavior that is under the control of the contents of the external inputs.

------------------------------- JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:47 EDT