Re: bugs in queue operations
Taylor R Campbell <[email protected]> Tue, 22 Dec 2009 09:47:33 -0500
| Newsgroups | gmane.lisp.scheme.scheme48 |
|---|---|
| Message-ID | <[email protected]> |
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. By the way, the patch introduced some mixed spaces and tabs, in case you care about making the whitespace consistent. 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?