We use ieantrt and ieantcr so I am familiar with them both. We never update the token we use it as a placeholder in block of storage.
Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Sep 23, 2012, at 12:54 PM, John McKown <[email protected]> wrote: > 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/> >>
