Stuart Halloway stuart.hallo...@gmail.com writes:
It is mort important to focus on the semantics (commutative or last-
one-wins) than the implementation details.
That's a tough pill to swallow. I understand the benefits of specifying
behavior to allow flexibility in an implementation, but here
Meikel Brandmeyer m...@kotka.de writes:
So using alter is the absolutely correct and nothing bad will
happen. However you might construct superfluous default nodes in case
the action is retried. They are not assoc'd to the map, though.
Understood. Thanks for the explanation.
The anonymous
If so, there's more to be explained about `commute'. I'm imagining the
commit-time rules saying that if competing changes to the refs touched
by `commute' can be ignored, because the changes can be applied in
either order. But if the operation was something like `inc', two
competing threads would
My application involves a graph with a node set, represented as map from
integral node ID to a node structure. Several threads need to look up
these node structures. This graph is constructed lazily, by which I mean
that the structures representing the nodes are only instantiated upon
first
Hi,
disclaimer: I'm completely incompetent in terms of the STM. The
following is my understanding what happens. It might be completely
wrong. Ignore at will.
On Mar 2, 2:40 am, Steven E. Harris s...@panix.com wrote:
(dosync
(or (*id-node-map* id)
(alter *id-node-map*
