Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 03/09/10 21:50, Tom Lane wrote:
>> Well, in that case what we need to do is presume that the latch object
>> has a continuing existence but the owner/receiver can come and go.
>> I would suggest that InitLatch needs to initialize the object into a
>> valid but unowned state; there is *no* deinitialize operation; and
>> there are AcquireLatch and ReleaseLatch operations to become owner
>> or stop being owner.
> I think we have just a terminology issue. What you're describing is
> exactly how it works now, if you just s/InitLatch/AcquireLatch.
No, it isn't. What I'm suggesting requires breaking InitLatch into two
operations.
>> We also need to define the semantics of SetLatch
>> on an unowned latch --- does this set a signal condition that will be
>> available to the next owner?
> At the moment, no. Perhaps that would be useful, separating the Init and
> Acquire operations is needed to make that sane.
Exactly. I'm not totally sure either if it would be useful, but the
current design makes it impossible to allow that.
BTW, on reflection the AcquireLatch/ReleaseLatch terminology seems a bit
ill chosen: ReleaseLatch sounds way too much like something that would
just unlock or clear the latch. Perhaps OwnLatch/DisownLatch, or
something along that line.
regards, tom lane
