
The Best Synchronization Is No Synchronization - nickb
http://www.flounder.com/no_synchronization.htm
======
mxh
"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.

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

