[Info-vax] OpenVMS, Locking, DLM, Range Locks (was: Re: Most popular application programming languages on VMS ?)

[Stephen Hoffman]

On 2019-01-12 03:03:10 +0000, Dave Froble said:

> I'm pretty sure that the DLM does not do any wildcard stuff with 
> resource name.  It uses only exact matches.

Correct.  The DLM does not include support for wildcards in resource names.

> Now, if the DLM knew about other types of locks, then it could treat a 
> resource name (or other data field) as a numeric range, and have a 
> routine to compare the data looking for intersections.

The DLM does not have support for range locks.

In current OpenVMS releases, that's all been implemented in the C RTL 
using system locks, and with a (minor) assist or two from the DLM.

> John is claiming it's in there.  I don't have sources.  Without 
> documentation, it might as well not be in there.

There was a discussion of this topic a while back.
https://groups.google.com/d/msg/comp.os.vms/e9PN_wNFOjg/gDyPzXSDDgAJ

Here's the core of the current range-locking implementation used by C 
on OpenVMS:
https://groups.google.com/d/msg/comp.os.vms/e9PN_wNFOjg/U90Yyss6DwAJ

> The CRTL's BRL is in there now via the fcntl() interface.
> 
> There essentially creates a bunch of DLM locks with the name 
> C$_deviceAAAABBBBCCCC where ABC is the hex representation of the FID.  
> 
> It uses sublocks to keep track of the ranges of bytes is it interested in.  
> 
> The scheme uses various blocking ASTs so each process gets notified of 
> another process accessing the range or attempting to also lock the 
> range (or part of the range).  
> 
> The range feature of the DLM simply allows some blocking asts to be 
> skipped since the CRTL would simply decide that the ranges don't 
> overlap and that there is nothing to do.
> 
> The code in the CRTL has to worry about overlapping ranges, combining 
> adjacent ranges, splitting large ranges into smaller ones, removing 
> system locks at image rundown, etc.
> 
> The code in the CRTL is split between DECC$SHR and DECC$SHRP since the 
> actual locking uses SYSTEM wide locks.
> 
> From reading the comments, the routines DECC$$BRL_ENQ, DECC$$BRL_ENQW, 
> DECC$$BRL_DEQ, and DECC$$BRL_GETLKIW were meant to be user-visible.  
> There are various probes and parameter checking.  I'm not sure if they 
> were ever described in public and I'm not sure of what sort of 
> application would use them directly.
> 
> To push BRL down to RMS or the XQP to provide the functionality to 
> non-C applications, it would have to worry about all the things the 
> CRTL does.  It would have to worry about more things like what does 
> byte-range locking mean for non-sequential files?  I assume you 
> wouldn't allow that since you can already lock records on indexed 
> files.  Do you want BRL on individual fields inside an indexed record?
> 
> I counted close to 7000 lines of code across both images.

At least until VSI gets the port out, range locking will either involve 
the CRTL, or will involve local range-lock locking code and that either 
with or without the assistance of the DLM.

Once that port is all sorted and VSI has some cycles for longer-term 
enhancement-related work, then I'd expect to eventually see range 
locking support migrated to the DLM, and related changes in the CRTL 
(that mostly removing and replacing the existing byte-range locking), 
in the XQP and RMS, as well as support for SSIO.  But that's not this 
decade, nor will it be early next.   And I'd hope those routines get 
renamed from DECC$$ to VSIC$ or DECC$ or some such; to names without 
the $$ private name, as was mentioned in the earlier thread.

Here's some semi-related light reading for you, David.  For anybody 
else interested in locking trends, as well.   "Efficient Locking 
Techniques for Databases on Modern Hardware"
http://www.adms-conf.org/kimura_adms12.pdf
The included citations in the references section will provide more than 
a little fodder for further pondering, too.





-- 
Pure Personal Opinion | HoffmanLabs LLC