Thread-Safety for Frames?

[Benoit Daloze]

Just a couple ideas:

* One way could be to change all nodes accessing the frame to additionally
synchronize on the frame.
This could be done in #spawn, and would have effect on both the passed
closure and the frame calling spawn.
Possible closures and other things capturing the frame before #spawn should
also be adapted to synchronize on the frame.

* Another way could be to look at the frame implementation and in #spawn
force all captured slots to go to a stable state like Object with
Frame.setObject(). This should then no longer needs synchronization at the
expense of boxing and a few more writes.

On Fri, Oct 21, 2016 at 3:54 PM, Stefan Marr <java at stefan-marr.de> wrote:

> 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/
>
>
>
>