Proposal: Thread-sealed containers

[Andrei Alexandrescu]

On 03/26/2011 05:26 PM, 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:
>
> 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".
>
> 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.
>
> 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.

Sounds like a good idea. Given the restriction, instead of one reference 
count per thread you only need a pair threadid + refcount. Then the 
refcounts of all other threads are implicitly zero.

Andrei