> On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote:
> Well, there's nothing that says you have to actually refer to locks by
> name. When I proposed this what I proposed is that the userlock module
> provide a dedicated means to map a lock name to a lock number, and
> reserve one of the 'lock spaces' (the 16 bit number) for this use,
just
> as one of them is currently reserved for locks based on OID. But I
also
> can't think of any reason why lock names need to be persistent, so I
> imagine you could store a list of lock names in shared memory with no
> backing storage.
Well, actually, as currently implemented the userlock module provides 48
bits of lock space but none of the bits are reserved for
anything...interface functions which assign the lower 32 bits to oid are
provided as a convenience. IIRC userlocks were first implemented in
1998 when the oid played a larger role, it is now quite rightly
deprecated and my intention is to remove it from the userlock module.
The new userlocks should be able to take advantage of refinements in the
locktag structure and provide a full 64 bits to resolve the lock at the
least. 64 bits is the magic number because it now works quite nicely
with sequences. Could you be more specific about how a string based
user lock system would be implemented?
Merlin
