Does anyone understand how to use "shared" types with concurrency send/receive functions?

[via Digitalmars-d-learn]

On Monday, 14 August 2017 at 03:59:48 UTC, Jonathan M Davis wrote:
> [snip]
>
> Now, the fact that the mutex objects don't handle shared 
> correctly is another issue entirely. Having to cast away shared 
> from mutexes is dumb, because you're obviously not going to be 
> protecting them with a mutex, and their operations have to be 
> atomic anyway for them to do what they do. So, that definitely 
> needs to be fixed. However, I believe that it _has_ been fixed 
> in master, and it might have made it into a release now, but 
> I'm not sure. So, core.sync.mutex.Mutex _should_ now be useable 
> as shared like it should be.
>

My fixes for shared(Mutex) - 
https://github.com/dlang/druntime/pull/1728 - are part of the DMD 
v2.074.0 release, and should propagate to LDC with their 1.4 
release respectively. GDC master now at druntime/phobos 2.074.1 - 
https://github.com/D-Programming-GDC/GDC/pull/539 and they're in 
the process of moving to 2.075.0 - 
https://github.com/D-Programming-GDC/GDC/pull/542.

Unfortunately, I forgot to write a changelog entry when I was 
working on the PR and later didn't have time to do so, before the 
2.074.0 release.

So shared (Mutex) should be in good shape now. I should 
supplement the ddoc unittest to address the transitive you issues 
you talked about. Currently it only shows synchronized use of a 
plain value type without indirections, which is uninteresting.
The example I'm thinking about is casting with HeadUnsharedOf / 
TailSharedOf a pointer to a singly-linked list, because with 
pointers you could show the shared(Node*) -> shared(Node)* 
transition in the type system, which unfortunately can't be 
demonstrated with implicitly reference types (classes).

Speaking of TailSharedOf, Jonathan could take a look at this PR: 
https://github.com/dlang/druntime/pull/1605? I and Andrei already 
approved it, but I'd like to get a third opinion since this is a 
breaking change and Martin seems be too busy the moment.