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.
