Comments on: Concurrency’s Shysters

By: Bryan Cantrill

Bryan Cantrill — Thu, 04 Dec 2008 21:53:12 +0000

David,
Thanks for the thoughtful comments — it’s always a relief when a fellow domain expert agrees! As for HTM, I’m skeptical that they do indeed gain over traditional techniques, especially for small critical sections. After all, I’m still doing read-to-own bus transactions (no way around that), and that’s a much greater cost than the pipeline stalls from a compare&swap. Further: are the scenarios in which HTM results in a higher performing system for the contended case or the uncontended case? If the former (that is, if HTM only putatively shows a benefit when contention is high), HTM is falling into a classic architecture pitfall: optimizing for the wrong case. In the Solaris kernel — as in any mature system with fine-grained parallelism — the vast, vast majority of locks are uncontended. (Indeed, that’s the whole damn point of fine-grained parallelism.) And when we do find a lock that has high contention, we take the steps necessary to defract or eliminate that contention — we don’t optimize for the contention itself.
My HTM skepticism is also heightened by the fact that the world has already had the opportunity to experiment with a flavor of HTM: namely, load-linked/store-conditional (implemented at least by Alpha and PowerPC). Now, there is obviously a difference between LL/SC and full-blown HTM, but if one is making the argument that HTM is essentially most useful for "very small critical sections", I think one needs to address what HTM would solve that LL/SC didn’t…

By: David Holmes

David Holmes — Thu, 04 Dec 2008 18:34:41 +0000

Here, here Bryan! As part of the core group involved in developing the Java Concurrency Utilities and having been teaching about concurrent programming in Java for over ten years, it was disheartening to read so much nonsense about the "CMT sky is falling". Does CMT impose additional challenges for effective concurrent programming? Sure. But there are so many fallacies in the arguments being put forward: the main one being that a single application needs to keep all of those core’s busy. I’m all for additional parallelism, but even then the simplistic programming models being advocated in a number of languages/platforms don’t even take into account that there are thresholds below which parallelizing a problem just doesn’t make sense. (Just because you can, doesn’t mean you should!).
As for TM, well I’ve long been a software TM skeptic, for the reasons you outline: TM relies on the ‘M’ and once you have real programs that need to handle other things transactionally (or rather has things that can’t be handled transactionally!) then STM breaks down. I’ve read, and reviewed, a lot of academic papers on STM, and as the authors try to expand their models to cope with things that are inherently non-transactional, the programming model gets more and more complex, to the point where I don’t believe that the resulting model is any better than "threads & locks" – far from it. Plus the performance is terrible too.
Hardware TM is a slightly different story. You can take advantage of HTM for very small critical sections code (that do only involve memory) and gain performance benefits over alternative techniques. And the programming model is somewhat simpler compared to lock-free techniques (but marginally so given the programming models at this low-level are fairly simple to begin with).
Regards,
David Holmes

By: Bryan Cantrill

Bryan Cantrill — Wed, 05 Nov 2008 15:37:06 +0000

Keith,
First, loved your follow-up to our work:
http://x86vmm.blogspot.com/2008/11/cantrill-and-bonwick-get-all-concurrent.html
Yes, the microkernel debate is another interesting analogue, and your observations are spot-on (and I say this as one who did kernel work for a microkernel operating system). Do you think there are enough of these for a book? "Locked in the Cellar: System Software’s Crazy Aunts, 1970-present"?
In terms of good faith: the problem I have is not that the TM folks are incorrect, it’s the arrogance of the sweeping assertions. Speaking personally, I have attempted to inject a little data/reality into the thinking of some TM partisans, if only to get them to narrow the scope of their assertions a bit. I have been roundly ignored each time. Perhaps not malice, but it is certainly true that there is a point at which malice and incompetence become impossible to distinguish from one another…

By: Keith Adams

Keith Adams — Wed, 05 Nov 2008 15:14:22 +0000

"Shysters" is, at least, uncharitable. The TM partisans are, in fact, wrong, and it’s becoming increasingly acceptable to say so in polite company. But I suspect that they’ve come to their wrongness in good faith…

By: Bryan Cantrill

Bryan Cantrill — Wed, 05 Nov 2008 14:59:36 +0000

RNC,
Yes, a good question — and I suppose another way in which the two-level/TM analogue holds up is that Sun had/has a major stake in both. The answer is that I’m not close enough to Rock to answer the implementation issue definitively — but when the TM issue was initially discussed in the CPU architecture committees in which I participated (in 2001), I did not withhold my skepticism. Rock is not — or should not be — "dependent" on TM. They have added support for it, and if some body of researchers or (less likely in my opinion) practitioners find that support useful, great. But TM in Rock should be a sideshow, not the main event…

By: Bryan Cantrill

Bryan Cantrill — Wed, 05 Nov 2008 14:54:26 +0000

UX-admin,
Peter’s right; check out those references for the architecture of the two-level model. It should also be said (and I don’t think I actually said it in my thesis) that the lab in which I worked had a Solaris source license. Having the source was instrumental in me being able to do my research — a fact which helped inform my bias towards open source after I arrived at Sun…

By: Peter Schow

Peter Schow — Wed, 05 Nov 2008 08:07:28 +0000

@UX-admin: Take a look at reference [9] and [8] in the mentioned thesis.

By: RNC

RNC — Wed, 05 Nov 2008 05:24:10 +0000

So what is your view on Harware Transactional Memory as implemented in Rock? A CPU upon which Sun Micro’s future appears dependent?

By: UX-admin

UX-admin — Wed, 05 Nov 2008 01:19:54 +0000

"This article is half stern lecture on the merits of abstinence and half Kama Sutra."
I love your writing style!
BTW, a carfeul reader will have noted that you already knew about the two-level scheduling model in Solaris. Given that at that time Solaris wasn’t open source, how did you know how threading was implemented in Solaris, before having actually been hired by Jeff to work at Sun?

By: Garrett D'Amore

Garrett D'Amore — Tue, 04 Nov 2008 09:50:01 +0000

Wow, an unbelievably excellent post on a topic that I have found myself wondering about as well. TM has seemed to me at least, to offer additional complexity without really solving the hard problems that I wind up using locks (and other synchronization primitives in the kernel) to solve, and your post puts to words what I’ve been feeling for a while. Thank you!