On 9/22/2012 12:55 PM, Binyamin Dissen wrote:
On Fri, 21 Sep 2012 08:20:38 -0700 Edward Jaffe <[email protected]>
wrote:
:>There are existing search/update models in which the "runner" performs its
:>search using only block-concurrent instructions (such as L) without
:>serialization and then checks later whether a retry is needed. A good example
is
:>IEANTRT. That code is FAST because the "retrieve" function never serializes
:>against the "update" function.
Wonder how the delete works. Perhaps it leaves the storage orphaned? Otherwise
the scan, if interrupted, could be left with a link pointer to nowhere.
A delete does not leave storage "orphaned", but it doesn't release it either.
The entry is simply made available for reuse by another create. The total amount
of storage required gradually increases until it reaches a high water mark. We
use similar techniques in some of our queue managers.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
[email protected]
http://www.phoenixsoftware.com/
