Is it really? Scaling today means running on more than one machine (google, facebook, twitter, etc.)
That means no shared memory. He helpfully makes this distinction on his front page ("I'm mostly interested in shared-memory system, so if you are looking for information about clusters, web-farms, distributed databases and the like, it's the wrong place")
According to Google's Jeff Dean, "to Google, multi-core computers look like separate servers with really fast interconnections" (i.e. memory).
So if you are running your applications on many machines anyway, you might as well drastically simplify your code by writing it "single-threaded" and running #cores copies on each machine.
I would add -- if you're expecting to make money off this, you're probably better off advertising your own consulting services -- at suitably high rates. You're the expert now... :-)
So far, nobody has mentioned the author's C++ based race detection tool. Conceptually it is similar to Corensic's commercial product, Jinx (http://www.corensic.com) but practically Jinx supports more languages, doesn't require recompilation, and is most likely much faster.
It's "similar" to a lot of software out there: Intel Thread Checker, Chord, Zing, Spin, RacerX, CheckFence, Sober, Coverity Thread Analyzer, CHESS, KISS, PreFast, Prefix, FxCop.
However, what you are missing is that most of these tools (and Jinx as far as I see, can't find clear description on the site, mostly vague marketing stuff) are of help to you if you are an application developer who writes in term of mutexes. While RRD is of help to you if you are implementing mutexes itself. Can you verify involved mutex algorithm down to possible memory access reorderings? I doubt.
> and is most likely much faster.
Or an order of magnitude slower.
Actually I'm not sure if it was supposed to be funny or serious. I see the funny "everything-free" list, as well as can imagine that there is some action you can do not atomically (relative to other actions) that gives you synchronisation.
I'm not quite sure what you mean, but synchronization without atomic operations is possible.
An example of mutual exclusion, without any atomic operations, taken from the book "The art of multiprocessor programming"[1] is (paraphrased) as follows:
Two threads, A and B, want to access some memory. Each thread has a flag.
When thread A wants to access the shared memory:
Set flag A
Wait for flag B to become unset
Access memory
Unset flag A
When thread B wants to access the shared memory:
Set flag B
While flag A is set {
Unset flag B
Wait for flag A to become unset
Set flag B
}
Access memory
Unset flag B
Obviously this isn't a general purpose solution, but rather an easy to understand example demonstrating that atomic operations are not required.
The intention was actually something like "atomic-RMW-free", that is "costly-operation-free". It should also include expensive memory fences, and excessive sharing.
I have an explanation of "atomic-free" in the Russian article, but I did not transfer it to the English page on xxx-free. Sorry for any confusion. I think I better just remove it from the main page for now.
[+] [-] chrisaycock|15 years ago|reply
[+] [-] zerothehero|15 years ago|reply
That means no shared memory. He helpfully makes this distinction on his front page ("I'm mostly interested in shared-memory system, so if you are looking for information about clusters, web-farms, distributed databases and the like, it's the wrong place")
According to Google's Jeff Dean, "to Google, multi-core computers look like separate servers with really fast interconnections" (i.e. memory).
So if you are running your applications on many machines anyway, you might as well drastically simplify your code by writing it "single-threaded" and running #cores copies on each machine.
[+] [-] sgt|15 years ago|reply
[+] [-] DaniFong|15 years ago|reply
[+] [-] hmottestad|15 years ago|reply
However I leave them there just as a reminder that someone is footing the bill.
If someone doesn't like ads, then they can use an ad blocker :)
[+] [-] codex|15 years ago|reply
[+] [-] dvyukov|15 years ago|reply
> and is most likely much faster. Or an order of magnitude slower.
[+] [-] viraptor|15 years ago|reply
Actually I'm not sure if it was supposed to be funny or serious. I see the funny "everything-free" list, as well as can imagine that there is some action you can do not atomically (relative to other actions) that gives you synchronisation.
Anyone?
[+] [-] dkersten|15 years ago|reply
An example of mutual exclusion, without any atomic operations, taken from the book "The art of multiprocessor programming"[1] is (paraphrased) as follows:
Two threads, A and B, want to access some memory. Each thread has a flag.
When thread A wants to access the shared memory:
When thread B wants to access the shared memory: Obviously this isn't a general purpose solution, but rather an easy to understand example demonstrating that atomic operations are not required.[1] http://www.amazon.com/Art-Multiprocessor-Programming-Maurice...
[+] [-] dvyukov|15 years ago|reply
[+] [-] kev009|15 years ago|reply