[concurrency-interest] updating a pure functional tree and CAS problems

jason marshall jdmarshall at gmail.com
Wed Mar 11 19:44:46 EDT 2009

On Tue, Mar 10, 2009 at 4:07 PM, Peter Veentjer <alarmnummer at gmail.com>wrote:

> Hi Guys,
>   The problems worsens if the number of things that need to
> be committed increase because it takes more time to build the new
> snapshot. It could even mean that long running transaction never can
> commit because some shorter running transaction take less time and let
> the long transaction try forever.

You say that like it's a bad thing.  Isn't that the essential complexity of
updating shared state?  The more state you touch, the harder it is for
anybody else to make progress.

In the database world, as you approach the cliff-face you start throwing
things overboard.  Either you rearrange your code so that the duration of
the change is shorter, or you find a way to split your update into two
partial updates, and then you deal with the intermediate state in the rest
of your data model.

I have always just accepted that this situation would happen in an STM
environment as well.  Maybe I'm giving up too quickly, but I don't see any
way around the problem.

- Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090311/46eafbae/attachment.html>

More information about the Concurrency-interest mailing list