record locking question - pretty urgent

[Kenneth Brody]

On 10/7/2013 12:57 PM, Fairlight wrote:
> On Mon, Oct 07, 2013 at 11:32:37AM -0400, Kenneth Brody thus spoke:
>> I assume what you are asking is:
>>
>> When an exclusive resource(*) lock is removed, and there are
>> multiple other processes already waiting to lock that same resource,
>> is it guaranteed that exactly one of thoses processes will obtain
>> the lock, and the rest continue to wait?
>>
>> Yes, that's the way exclusive(**) locks work.
>>
>>
>> (*) A "resource" can be a contiguous region of bytes within a file.
>>
>> (**) There are also non-exclusive locks available.  For example,
>> some systems allow "read locks" and "write locks".  There can be
>> multiple "read locks" on a given resource, but a "write lock" is
>> exclusive.
>
> That is correct.  I wanted to make sure a race condition wouldn't let two
> records think they grabbed the exclusive lock at the same time.

They wouldn't be "exclusive" then, would they?

> That said, the order in which they lock is -NOT- guaranteed to be FIFO, am
> I correct?  It's totally dependent upon lock release time vs subsequent
> lock attempt times, and affected by CPU timeslice skewing?

My understanding is that there is no set order in which the waiting 
processes would get the lock once released.  Certainly nothing you should 
depend on.

> Further question:  The protected lookup is blocking by default, is it not?
> Richard's example showed using LOCKED(), but he also had a -w flag on his
> lookup, and I've never seen that flag before.  By default, protected
> lookups just spin and wait for their turn at the resource trough, yes?

Without the "-w", filePro will wait (not "spin and wait", since it's a 
blocking call, and filePro will get no CPU until the lock is obtained) for 
its turn to have the lock.

With the "-w", filePro will immediately return if the record was locked, 
having failed the lookup, and with "LOCKED(lookupname)" returning "true".

-- 
Kenneth Brody