concurrency call to arms

[Russel Winder]

On Wed, 2018-08-22 at 12:00 -0700, H. S. Teoh via Digitalmars-d wrote:
[…]
> 
> I approached the article from a language-independent viewpoint. While
> I
> know a little bit of Python, I wasn't really very interested in the
> Python-specific aspects of the article, nor in the specific
> implementation the author had written.  What caught my interest was
> the
> concept behind it -- the abstraction for concurrent/parallel
> computation
> that is easy to reason about, compared to other models.

But I see nothing new in the concept (unless I am missing something):
scatter/gather parallelism has been a staple part of parallelism for
more than 35 years, and that is what this model is about.  

> The main innovative idea, IMO, is the restriction of
> parallel/concurrent
> processing to the lifetime of an explicit object, in this case, a
> "nursery". (TBH a better term could have been chosen, but that
> doesn't
> change the underlying concept.)  More specifically, the lifetime of
> this
> object can in turn be tied to a lexical scope, which gives you an
> explicit, powerful way to manage the lifetime of child processes
> (threads, coroutines, whatever), as opposed to the open-endedness of,
> say, spawning a thread that may run arbitrarily long relative to the
> parent thread.

Another name for scatter/gather for the last 35+ years is
farmer/worker, which is just another way of describing this nursery.
Unless I am missing something, this is just new terminology for the
same abstraction.

> This restriction does not limit the expressive power of the
> abstraction
> -- it "gracefully degrades" to current open-ended models if, for
> example, you allocate a nursery on the heap and spawn child processes
> /
> threads / etc. into it.
> 
> However, by restricting the open-endedness of child (process, thread,
> ...) lifetime, it gives you the ability to reason about control flow
> in
> a much more intuitive way.  It restores the linearity of control flow
> in
> a given block of code (with the well-defined exception if a nursery
> was
> explicitly passed in), making it it much easier to reason
> about.  Unless
> you're explicitly passing nurseries around, you no longer have to
> worry
> about whether some function you call in the block might spawn new
> processes that continue running after the block exits. You no longer
> need to explicitly manage shared resources and worry about whether
> resource X could be released at the end of the block. And so on.
> 
> Even in the more complex case where nurseries are being passed
> around,
> you can still reason about the code with relative ease by examining
> the
> lifetime of the nursery objects.  You no longer have to worry about
> the
> case where background processes continue running past the lifetime of
> the main program (function, block, etc.), or manually keeping track
> of
> child processes so that you can sync with them.
> 
> Once you have this new way of thinking about concurrent processing,
> other possibilities open up, like returning values from child
> processes,
> propagating exceptions, cancellation, etc..  (Cancellation may
> require
> further consideration in non-Python implementations, but still, the
> model provides the basis for a cleaner approach to this than open-
> ended
> models allow.)

I am not sure I see a difference between nursery and threadpool or
executor. Everything that is being said about this nursery can be said
of threadpools and executors so it seems to be just a relabelling of a
system already available.

I am not trying to attack the idea of nice management of concurrency
and parallelism, I have been railing against crap parallelism for 35+
years. What worries me is that there is a claim of something new here
when there appears not to be something new, it is a relabelling of a
known concept.

> 
> […]
> > > Indeed.  It certainly seems like a promising step toward
> > > addressing
> > > the nasty minefield that is today's concurrent programming
> > > models.
> > 
> > I'd say processes and channels works just fine. What is this really
> > providing outside the Python sphere? (Also Javascript?)
> 
> [...]
> 
> Functionally, not very much.
> 
> Readability and understandibility-wise, a lot.

Really? I am not convinced.

There is a danger of mixing management of processes/tasks/threads with
managing data. Programmers should never have to manage
processes/tasks/threads the framework or language should handle that,
programmers should be worried only about their data and the flow and
readiness of it.

> And that is the point. I personally couldn't care less what it
> contributes to Python, since I don't use Python very much outside of
> SCons, and within SCons concurrent processing is already taken care
> of
> for you and isn't an issue the user needs to worry about. So in that
> sense, Trio isn't really relevant to me.  But what I do care about is
> the possibility of a model of concurrency that is much more easily
> understood and reasoned about, regardless of whether the underlying
> implementation uses explicit context-switching, fibres, threads, or
> full-blown processes.

We are on the same page on that wish, that is certain.

> Basically, what we're talking about is the difference between a
> control
> flow graph that's an arbitrarily-branching tree (open-ended
> concurrency
> model with unrestricted child lifetimes: one entry point, arbitrary
> number of exits), vs. a single-entry single-exit graph where every
> branch eventually rejoins the parent (nursery model). Having an
> arbitrarily branching control flow means many concepts don't work,
> like
> return values, propagating exceptions back to the parent, managing
> child
> lifetimes, etc..  Having well-defined joining points for all children
> means that it's possible to have well-defined return values,
> exception
> propagation, manage child lifetimes, etc..

But should the programmer care about the details of the
tasks/fibres/processes? Shouldn't a task/fibre/process terminate when
it has finished providing the data. Lifetime should be tied to the data
not to some arbitrary notion of code. This is the core of why the
analysis of Go is wrong here. goroutines without channels are
meaningless. The papers undermines goroutines without understanding how
they are used is Go.

Dataflow, actor, CSP, fork/join, etc. implementing various scatter
gather strategies already cover the abstraction of "nurseries", and
thus cover the problems you highlight. The abstractions already exist,
and "nurseries" do not seem to add anything new.

> I don't claim this solves all the difficulties of comprehension in
> concurrent programming, but it does reduce the mental load by quite a
> bit. And that to me is a plus, because reduced mental load means the
> programmer is more likely to get it right, and can spend more effort
> actually focusing on the problem domain instead of wrestling with the
> nitty-gritty of concurrency.  More productivity, less bugs.  Like
> using
> a GC instead of manual memory management.  Or writing in D instead of
> assembly language. :-D

Concurrent programming already has ways of providing a good UX.  At
least there are lots of frameworks for this for most programming
languages in various guises.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20180823/f158e960/attachment-0001.sig>