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?

Linus