Re: bugs in queue operations

Michael Sperber <[email protected]> Tue, 22 Dec 2009 15:53:56 +0100
Newsgroups gmane.lisp.scheme.scheme48
Message-ID <[email protected]>
Taylor R Campbell <[email protected]> writes:

>    Date: Tue, 22 Dec 2009 15:15:25 +0100
>    From: Michael Sperber <[email protected]>
>
>    Taylor R Campbell <[email protected]> writes:
>
>    > Several queue operations have optimistic concurrency bugs because they
>    > don't use provisional readers and writers.  For example, if you call
>    > QUEUE-LENGTH twice in a single transaction without performing any
>    > destructive operations on the queue in the meantime, it should, but
>    > doesn't, return the same answer both times, whether or not other
>    > threads have committed changes to the queue.  The problem is that
>    > QUEUE-LENGTH uses the non-provisional LENGTH.  At the end of this
>    > message is a program demonstrating this bug.
>
>    Thanks for the report - I just pushed a patch (from Robert Ransom -
>    thanks!) to fix the problem.
>
> Hmm...  I have to say that the new implementation looks even more
> complicated than the old one.  Was there a particular reason not to
> use <http://mumble.net/~campbell/darcs/scheme-cml/s48-optimistic-queue.scm>?
> I wrote it specifically to be compatible with the existing interface,
> and to my mind at least it seems simpler and easier to reason about,
> but maybe that's just because I wrote it.

Yours and the one in place seem pretty much equivalent, in terms of the
changes you made.  Robert's code addresses a few more concerns than
yours, namely, the fact that proposals and exceptions don't interact
well. Robert's implementation is also a bit more in line with the coding
style of the stuff around it.  (It also helped that he sent me a
Mercurial bundle, which as easier for me to integrate.)

> I also notice that the new code discusses performance of the various
> queue operations.  Have you considered replacing it by a functional
> data structure, and storing it in a cell, to reduce the number of
> provisional references to a queue per transaction from O(f) to O(n
> |---> 1), as a function of the number of memory references performed
> by queue operations in the transaction?

Not yet, but it's probably the way to go at some point.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla