Stewart Stremler wrote:
So instead of Test And Set, we have Compare And Swap as our atomic
operation. Okay. This is less clever than it first seemed, as it's a new
atomic instruction.
Not really. Compare and Swap and Test and Set are isomorphic. If you
have one, you can do the other.
The issue is that you *must* have an atomic hardware instruction and you
will need some form of memory barrier instruction. All modern
microprocessors have had this for quite a while. It's not a big burden.
Still, this sort of atomic instruction offers some interesting ways to
tackle concurrent programming problems -- and is the sort of thing that
probably _ought_ to be introduced into concurrent languages.
See: "Purely Functional Data Structures" by Okasaki. The issue is how
to create a data structure that persists even while being mutated or,
alternatively, to create efficient data structures that persist even as
newer versions are getting created.
Warning: Okasaki makes my brain hurt.
Atomicity is the hard nut. If we could have a language that had atomic
sections, we'd probably have a lot more fun with concurrent programming.
I'd *love* to be able to say:
atomic {
do_something();
do_something_else();
}
But that's probably a really hard feature to implement. :)
Congratulations, you just described "Composable Memory Transactions".
http://research.microsoft.com/~simonpj/papers/stm/stm.pdf
This is one of the cornerstones of Shared Transactional Memory.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
