[Info-vax] DCL, DLM, APIs, RAS, RuleWorks, etc

[Arne Vajhøj]

On 10/27/2022 8:30 PM, Dave Froble wrote:
> On 10/27/2022 7:18 PM, Arne Vajhøj wrote:
>> But if you want my take, then I think below would be good for 98% of 
>> cases.
>>
>> Procedural:
>>
>> lckid = lib$enqw(resnam, lockmode, flags)
>> ...
>> lib$deq(lckid)
>>
>> OO:
>>
>> lck = new Lock(resnam, flags)
>> lck.get(lockmode)
>> ...
>> lck.release()
>>
>> Obviously something additional would be required for the 2% with
>> advanced requirements for async, but there are newer ways to
>> do async as well.

> Your biggest problem is that you're still thinking of a resource name.  
> I think it would be trivial to add multiple lock types, with no 
> specification defaulting to resource name, and a second type would be a 
> numeric range.  As for a third, I have no idea, at this time.

The traditional lock model is that:
* locks are just identifiable with no implied semantics
* the applications acquire and release (lock and unlock)
* the lock manager just administer locks it does not
   actually block anything so applications need to be cooperative

In that model the identifier could be a name or a number.
A name is a superset of number, so it sort of makes sense.

Numeric ranges is different. Well if 0-100 is just an id
like "0-100" then it fits above. But if there are
semantics like a lock on 0-100 actually blocks
a lock on 50-150 then it is a totally different model.

Arne