[dmd-concurrency] composability

[Kevin Bealer]

So, if I understand correctly, the main thing the shared provides (relative
to, say, an implicitely shared global in in gcc) is (relatively) simple
memory barriers in the right places as well as compare and swap, which can
be used to do lock-free style programming?

One thing that strikes me as potentially tricky with the lock free style --
it seems like it isn't composable at all.  What I mean is that even if you
get a really high quality and fast lock-free hash map running, if you need
to take something (a struct, say) out of the hash map, do something with it,
and then put it back in, you can write shared lock-free logic for the
struct, and for the hash map, but you can't easily make the entire operation
of take-out, update, put-back lock free in any easy way, right?

On a theoretical level, these are cool structures but it seems like we will
still have the problem that Java 1.0 had, which is that it had thread save
Vector primitives but there was no way to enforce consistency between them.
Consistency only refers to one of the two lists at a time.

Likewise, if you have a struct with one integer you can do CAS.  If you have
two integers, you can figure out a 2-word CAS, but then if you have three
you are sunk again.  If you come up with a trick for three, you lose with
four.

Since D has such great built in containers, doing things like associative
arrays as lock-free seems great.  But I'm thinking the majority of the time
for ordinary users, this feature would be used either for simple insert,
singly linked list, or fall back to a spin lock to surround all your
operations (in which case you lose the guarantee that one thread can pause
without hanging the app.)

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100106/51edaf5a/attachment.htm>