Proposal: Thread-sealed containers

dsimcha dsimcha at yahoo.com
Sat Mar 26 15:26:47 PDT 2011


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.


More information about the Digitalmars-d mailing list