Creating a future/promise object

[Frank Pagliughi via Digitalmars-d]

> The delegate could send a message to user code in another 
> thread/fiber. In any case it removes a blocking get_result() 
> and possibly the need for get_result_timeout().

That sounds interesting, and I will look into it. (Questions to 
follow, no doubt).

But we've gone down a path at a specific solution, though my 
original curiosity is a little more general. Say I want to create 
a new class to synchronize threads in a way that is not currently 
supported in the library. In the spirit of modern D concurrency, 
I would want to declare the class as shared:

   shared class MyAmazingSyncObject { ... }

I've stumbled upon a few examples of this, but they all seem to 
use atomics internally. Say I want to use the traditional 
lock-based objects from the core sync library (mutexes, condition 
variables, etc). Those objects are not declared as "shared", 
though I would think they should be.

What is the purpose of a mutex or condition variable if not to be 
shared across threads?

And since they are not shared, they make using them from a 
higher-level class difficult.

I ask this from the perspective of a library writer. I don't mean 
to push traditional, lock based paradigms going forward, but 
internal to some new, high-order data passing algorithm, a lock 
or signal might be handy.