concurrency call to arms

[H. S. Teoh]

On Thu, Aug 16, 2018 at 08:30:26PM +0000, John Belmonte via Digitalmars-d wrote:
[...]
> (Andrei, I hope you are reading and will check out
> https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
> and https://vorpus.org/blog/timeouts-and-cancellation-for-humans/)

I read both articles, and am quite impressed by the revolutionary way of
looking at concurrency.  It provides a clean(er) abstraction that can be
reasoned about much more easily than currently prevalent models of
concurrency.  Seems it would fit right in with D's message-based
concurrency communication model.


[...]
> These are novel control structures for managing concurrency.
> Combining this with cooperative multitasking and explicit,
> plainly-visible context switching (i.e. async/await-- sorry Olshansky)
> yields something truly at the forefront of concurrent programming.  I
> mean no callbacks, almost no locking, no explicitly maintained context
> and associated state machines, no task lifetime obscurity, no manual
> plumbing of cancellations, no errors dropped on the floor, no shutdown
> hiccups.  I'm able to write correct, robust, maintainable concurrent
> programs with almost no mental overhead beyond a non-concurrent
> program.

Indeed.  It certainly seems like a promising step toward addressing the
nasty minefield that is today's concurrent programming models.

However, it would seem to require language support, no?  It's going to
be a tough sell to Walter & Andrei if it requires language support.
(Though IMO it's worth it.)

One potential problem point is C/C++ interoperability.  Once you can
call into the wild world of arbitrary C/C++ code that may spawn threads
and do other low-level concurrent things, all bets are off and you can
no longer provide the above guarantees.

But we might be able to work around this with a mechanism similar to
@safe/@system/@trusted, to isolate potentially encapsulation-breaking
code from code that's been vetted to not have unwanted concurrent
side-effects.  Then within the realm of "well-behaved" code, we can reap
the benefits of the new concurrency model without being crippled by the
potential of interacting with "badly-behaved" code.


[...]
> I'd like to see a D library supporting these control structures (with
> possibly some async/await syntax for the coroutine case).  And of
> course for vibe.d and other I/O libraries to unify around this.

If this is possible to implement without requiring language support,
that would be a major win, and would be much more likely to be
acceptable to W & A.


> I'll go out on a limb and say if this could happen in addition to D
> addressing its GC dirty laundry, the language would actually be an
> unstoppable force.
[...]

Not sure what you're referring to by "GC dirty laundry", but IMO, the GC
gets a lot of undeserved hate from GC-phobic folk coming from C/C++.
While there's certainly room for improvement, I think the GC ought to be
regarded as one of those modern features that are essential to D's
success, not the illegitimate step-child that everyone tries to avoid.
It liberates the programmer from being constantly bogged down with the
nitty-gritties of low-level memory management issues, and frees the mind
to focus on actually solving the problem domain the program is intended
to address. Just like this new concurrency model liberates the
programmer from constantly having to worry about data races, deadlocks,
and all the other nice things traditional concurrency models entail. ;-)


T

-- 
For every argument for something, there is always an equal and opposite argument against it. Debates don't give answers, only wounded or inflated egos.