Re: The place of Concurrency (in c++)

[Larry Dickson <tjoccam@xxxxxxxxxxx>]

Hi Ruth,

I do think you are "missing the plot." The plot is that C++, as an object-oriented language, is designed to abstract away time and data flow. I just presented an unscheduled short talk at WORLDCOMP 2013 (still going on in Las Vegas) in which I claimed that "Deep Computing" (which includes object-oriented and all other namespace-oriented abstraction languages) is modeled on LAW, while our stuff ("Wide Computing") is modeled on NATURE.

In law, the consequences are instantly implicit in the inputs (just as on your tax return), while in nature, independent self-contained things are continually communicating with each other over time. It's not quite true that "never the twain shall meet," because you can have an "occam harness" or "plum pudding" where the plums can be as Deep as they want. From that point of view, there is need to define how a full-up C++ (or Java or whatever) entity transmits to, receives from, or is stimulated by an entity entirely outside itself.

If it can be made responsive, or - better yet - the question of responsiveness be made unimportant by EXPLICITLY PROGRAMMED FIFOs in "pudding land", then its "horribly messy" syntax when attempting multitasking within itself can be ignored. Let OO be itself - a big sequential event-based thing that traipses through an agenda on a uniprocessor.

Larry

On Jul 24, 2013, at 9:43 AM, Ruth Ivimey-Cook <ruth@xxxxxxxxxx> wrote:

> Folks,
> 
> I have just become aware (shame on me!) of some really excellent video talks by Herb Sutter on the website http://cppandbeyond.com, including this one talking about Concurrency:
> http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Herb-Sutter-Concurrency-and-Parallelism
> 
> It is somewhat long, but IMO it's worth thinking about.
> 
> In one sense I am glad C++ is moving beyond mutexes at last, but I kept wanting to ask about the CSP concepts. Near the start of the talk Herb introduces a log writer, comparing a mutex implementation to a queues based one. The queues based one (i.e. send() a message to a worker thread) was presented as if it was forever committed to being asynchronous, while a simple receive() of an ack would have enabled synchronous action. In the talk as a whole, "blocking == bad", which in one respect is a good thing, but it's also a dangerous thing to run away with, I think. Blocking is bad in the extreme, but it's essential sometimes.
> 
> Herb also talked about using "futures" - result-variables used to access an async value - and the possibility of avoiding a wait() on the future value by using "then()" actions to append another function to the existing thread.
> 
> It all seems so horribly messy and - to say the least - the syntax is getting worse than perl 4.
> 
> Is there anything we as a community can do to inject another viewpoint into this debate? Herb and his colleagues are no doubt very respected and very intelligent people, and yet they (and the rest of the C++ standards board) seem to be making such an awful mess of what should be such a simple idiom.
> 
> ... or is it me that is missing the plot?
> 
> The good thing about this is that people are talking about the issues, are aware of things like deadlock, and are no longer head-in-sand about it. And that things are changing, both in the standards and elsewhere. And therein lies an opportunity.
> 
> Regards
> Ruth
> 
> -- 
> Software Manager & Engineer
> Tel: 01223 414180
> Blog: http://www.ivimey.org/blog
> LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/
> 
> 
>