[cpp-threads] High-level concurrency issues

[Nick Maclaren]

"Herb Sutter" <hsutter at microsoft.com> wrote:
> 
> The analysis you gave below is a summary of your 1992 paper, and pretty
> much follows from the design requirements laid out at the beginning of
> that paper. I buy into most of the design requirements, but not this one
> (quoting the paper):
> 
>   Both synchronous and asynchronous communication are needed. However,
>   we believe that the best way to support this is to provide
>   synchronous communication as the fundamental mechanism; asynchronous
>   mechanisms, such as buffering or futures [9], can then be built when
>   that is appropriate. 
>             
> I don't buy into that part, because that makes blocking the default, and
> implicit blocking is one of the big problems with today's concurrent
> programming models that we need to overcome. (Another big one is of
> course better isolation, or how to reduce or eliminate mutable shared
> state and the need for locks.)

Absolutely.  This is one of the reasons for the ghastly I/O performance
of modern systems.  On MVT, I could get 90% of theoretical peak from
an unmodified Fortran program on multiple devices WITHOUT the use of
massive buffers.

> It's been clear to me that asynchronous (aka nonblocking,
> message-passing) has to be the default when communicating between
> threads. Certainly Lawrence at least seems to agree that futures are a
> key abstraction.

Absolutely.  It is trivial to build synchronous protocols out of
asynchronous ones and provably impossible to do the converse.

> Your paper's design requirements paragraph about this continues:
> 
>                        Building synchronous communication out of
>   asynchronous mechanisms requires a protocol for the caller to
>   subsequently detect completion. This is error prone because the
>   caller may not obey the protocol (e.g. never retrieve a result).
> 
> The above is actually pretty trivial in the implementation (e.g., think
> of a future<T> containing just a shared_ptr<FutureData<T>>). In the
> programming model it's easy too: The caller doesn't create a future for
> the result at all, or creates one but then lets it go away without
> touching it to get the result. Maybe I'm misunderstanding. Probably
> whiteboard material.

If you are misunderstanding, I am, too.  ALL you have to do to create
a synchronous protocol out of an asynchronous one is to encapsulate
in the following way:

Synchronous action:
    Start asynchronous action
    Wait for it to complete

Yes, it really IS that trivial.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679