The Best Synchronization Is No Synchronization

"Programs developed using this [sic] techniques are significantly easier to write, debug, and maintain than programs written with mutexes, CRITICAL_SECTIONs, or semaphores."

No, they damn well aren't. Or, at least, not always. Like most things, it's horses for courses.

This article got under my skin because I had the distinct "pleasure" of maintaining/debugging/enhancing a system designed according to these principles. The problem that crops up over and over and over is that one wants to compute f(X, Y), where X and Y are members of different objects, assigned to different threads. So, one must send messages to retrieve the values and trigger a computation .... and then the result of the computation has to make its way back to the caller.

It. Fucking. Sucks.

I'm sure this isn't a problem if the data is laid out just so, and the system never diverges from its original design, etc. But there are cases where a mutex would be just fine, thank you very much.

As an aside: Can performance considerations _really_ play a role in arguing for messaging as a interthread communication solution? Even if you can construct an environment specific argument that messaging has lower overhead than mutexes (and I find the linked article unconvincing) isn't the latency going to go through the roof? Doesn't that matter?

Bah. Another example of taking something hard and simple, trying to make it easy and complicated, and leaving it instead hard and complicated.

Nice find! That guy has lots of good stuff on his site.