Thread-Safety for Frames?

[Stefan Marr]

Hi:

I am currently sketching a simple fork/join implementation for SOM and I noticed that frames are not safe for use in such environments.

Let’s imagine a language that allows to change variables in other lexical scopes and has threading and/or fork-join style shared memory concurrency:

fun foo() {
var race := nil;
var task1, task2;

task1 := spawn { race := 1 };
task2 := spawn { race := 4.2 };

task1.join();
task2.join();

assert race == 1 || race == 4.2;
}

So, the important part above is that we capture the frame of foo() in the two tasks created by `spawn`, which then try to modify it concurrently.

The problem I see is that the type information and the actual slot value are not updated atomically in the MaterializedFrame implementations.

So, what can happen is that the `assert` fails because task1’s write to the type info succeeds first, and then task2 gets interleaved setting the slot type to double and the value to 4.2. Eventually, the value write of task1 overwrites the value to the bit pattern of an int of 1, which is the subsequently interpreted as a double.

Is this something that should be considered a bug?
Are there any solutions to make outer lexical frames thread safe in the way that they never produce out-of-thin-air values?

Thanks
Stefan


-- 
Stefan Marr
Johannes Kepler Universität Linz
http://stefan-marr.de/research/