D2 Multithreading Architecture

[Robert Jacques]

On Wed, 29 Apr 2009 09:12:52 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:
> Denis Koroskin wrote:
>> The proposal sound reasonable, but it's hard to follow. I really can't  
>> comment on it because I didn't fully understand it.
> [...]
>> I believe your proposal suffers from it, too. For example, when reading  
>> an introduction, I see this:
>>
>>> ┌──────────────┐
>>> │ Overview     │
>>> ├──────────────┼─────────────────┬─────────────┬──────────────┐
>>> │ Hierarchy    │ Description     │ Ownership   │ Transitivity │
>>> ├──────────────┼─────────────────┼─────────────┼──────────────┤
>>> │ scope        │ super-interface │ unknown     │ deep†        │
>>> │  ││└─stack   │ current scope   │ stack       │ implicit     │
>>> │  │└──local   │ object default  │ local-heap  │ deep†        │
>>> │  ├───shared  │ thread safe     │ shared-heap │ deep†        │
>>> │  └───mobile  │ unique objects  │ shared-heap │ shallow      │
>>> └──────────────┴─────────────────┴─────────────┴──────────────┘
>>  You tell that you introduce 5 different qualifiers but you don't  
>> explain why are they needed. Why not 4, not 3? What problem each of  
>> them solve? All I can do is guess and be proven wrong, that's the most  
>> frustrating.
>
> I agree. I also find the article hard to follow. I'm seeing some  
> features discussed and all of a sudden "this solves that problem". I  
> didn't have the time for a closer read, but I think I'll have a hard  
> time understanding how this proposal works.

The paragraph immediately underneath the summary table explains each type  
and its rational. Although in retrospect it might have been better to put  
the text before the table.

Here’s an alternative explanation.

For each memory location there’s one type
1) stack, for things allocated on the stack
2) local, for things allocated on the thread local heap
3) shared, for things allocated on the shared heap (i.e. multi-threaded  
objects)

Then you have one common type, like const to simplify writing functions  
and reduce code bloat:
4) scope, the thing everything ownership type can implicitly cast to

And lastly, I included a unique / mobile type for three reasons.
1) There’s a need for objects private to a shared object. These are  
protected by the parent shared object and don’t need or want (slow)  
protection of their own. Mobiles are perfect for this, but they should  
handle the majority of cases.
2) There is a need to cheaply pass data between threads, which mobiles are  
perfect for, and doing so in a library type would require relying on using  
unsafe types with usage conventions for safety, which is a recipe for  
disaster.
3) There are advantages to have the type system be aware of mobiles, with  
regard to generic scope functions (see scope rule 6b)