Kevin Lewis wrote:
> Cycle locking addresses the continued existence of an object while
> there may be pointers to it. The problem we have here is that there
> is a pointer within the record to a data buffer. That pointer can go
> away at any time, even an instant after a call to hasData(). It takes
> two steps to use the data buffer; 1) Ask whether the record is
> chilled or hasData(), 2) Use the data buffer.
> We need to surround these with some kind of SyncObject. Otherwise,
> there is no guarantee that a data buffer will be available, even if
> you check for its existance first. Cycle locking protects objects tat
> threads have pointers to. We need to protect the pointer.
If the actual deletion of the record data were deferred until after the
current cycle, the pointer would remain valid. It delays the
reusability of the memory, but is near infinitely faster than taking a
lock and releasing a lock on every record fetch cycle.
RecordVersion::thaw might even try to fetch the purged data back from
the purgatory (anyone have a better word? It certain is the the obvious
name for something where things waiting to be purged to be put.)
Is hasData() the same as hasRecord()?