Proposal: Thread-sealed containers

[Jason House]

dsimcha Wrote:

> I'm thinking about ways to make std.concurrency's model more flexible 
> without compromising safety.  It's sometimes useful to cheaply _move_ 
> (as opposed to share or copy) data between threads.  I wonder if we 
> could co-opt sealed containers here:

What definition of sealed are you using? A quick web search mostly brought up C#'s sealed keyword which I think is the same as D's final. I vaguely remember Andrei might have used the term to mean no aliases to the data held by the container?

> 1.  Define basic data structures like arrays, hash tables and trees that 
> are otherwise identical to sealed containers, but maintain a 
> _thread-specific_ reference count.  This can be naively implemented as a 
> hash table with Thread keys and size_t values, but there's probably a 
> better way.  Provisionally call these "thread-sealed containers".

It might be possible to simply store the owning thread id. Since the thread that sent the container will still have a reference to it, you may be forced to do some extra runtime checks on every method call anyway...

> A thread-sealed container has the invariant that no two thread-specific 
> reference counts may be simultaneously nonzero.  If this becomes untrue, 
> an Error is thrown at runtime.  This is not as good as a compile time 
> error, but it's much better than a low-level data race.
> 
> 2.  Restrict the contents of thread-sealed containers to types that can 
> be safely shared/moved between threads:  Primitives, shared and 
> immutable data, and other thread-sealed containers.

Some kind of equivalent to assumeUnique may be needed here?

> 3.  Define a std.concurrency.moveSend() function.  This function takes a 
> thread-sealed container by reference, decrements the sending thread's 
> reference count, enforces that it's zero, then sends the container as a 
> message to the receiving thread.  The receiving thread increments its 
> reference count of the container.

I like that you're thinking about this kind of stuff. I am over tired right now and haven't really thought this through, but it feels like this could lead to a major safety upgrade for std.concurrency.