Linus Torvalds (torvalds@osdl.org) on 10/26/06 wrote:
---------------------------
>Rob Thorpe (rthorpe@realworldtech.com) on 10/26/06 wrote:
>>
>>* A language is SAFE2 if a function cannot recieve
>>arguments that can cause that function to behave
>>unpredictably, only trigger error.
>
>I don't think you can ever consider any threaded language
>"SAFE2" if they can see each others data (ie if you allow
>communication between threads).
>
>So a purely functional language may be "SAFE2" even in
>threaded environments, but it effectively limits the
>threads to be self-contained and never have any shared
>data (apart from initial state) at all.
>
>Once you have shared data that threads can modify (ie
>no longer just initial state), threads by definition will
>give you the ability to behave unpredictably, if only
>because of access order issues.
>
>And the Java memory model is definitely not even just
>about access ordering, since it allows read re-ordering,
>so two different CPU's running the exact VM code can
>actually see different results for the same exact code,
>simply because the CPU's could have different instruction
>window depths.
>
>Now, with enforced locking, you could get something that
>is very close to SAFE2, apart from the actual ordering of
>entering critical sections. I think that's a useful (but
>still not deterministic) safe mode to have. But
>that has nothing to do with memory ordering - or rather,
>it enforces the situation that memory ordering can never
>matter.
>
>So it looks like Java has no chance at all of being
>SAFE2. At best, you can be SAFE1 - avoiding the VM crashing.
>
>Or did I misunderstand your SAFE1/SAFE2?

I don't think I defined it very well. What I was looking for is more:
* SAFE1 = You can't crash the VM
* SAFE2 = You can't crash a function in the VM

"Unpredictable" was the wrong way to put it. You can always dream up arguments or data-structures to make a function behave unpredictably in almost any language, but in some such unpredictably behaving function can still be gauranteed not to crash in some.

I suppose you could phrase the issue like this:-

* SAFE1 = You can't crash the VM
* SAFE2 = You can't crash a function in the VM
* SAFE3 = Data a function call recieves is always consistent

SAFE3 is much harder to define, but I expect you know what I mean: code does what you expect it to do.

It seems to me that Java can be SAFE1 & SAFE2, but not SAFE3 with threads.