[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

The place of Concurrency (in c++)


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:

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.


Software Manager & Engineer
Tel: 01223 414180
Blog: http://www.ivimey.org/blog
LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/