Isn't this kind of how one uses cell pool storage? I'm setting on the back porch, typing on my tablet, and too lazy to get up and research it. On Sep 22, 2012 5:04 PM, "Edward Jaffe" <[email protected]> wrote:
> 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/ <http://www.phoenixsoftware.com/> >
