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