Re: VAX Ada Tasks and VMS Lock Manager

[kilgallen@eisner.decus.org (Larry Kilgallen)]

In article <01bc965a$b5135f60$88ecced0@jpeterson>, "Jay and Cathy Peterson" <JPeterson@PCBYTE.net> writes:

> Next, perhaps some context is in order: The VAX Ada and VMS versions were
> included so that, on the off chance Digital significantly changed the
> operation of the Ada RTL and (Open)VMS Lock Manager in the intervening
> years, you would know where I was coming from. No offense was intended :)

Certainly all on c.l.a appreciate the inclusion of version information,
even if only to avoid protracted discussion of implementations which do
not concern them. There were no design changes made public that I recall,
but I was slightly overwhelmed when I consider how many bug fixes are
encompassed in the versions released since then (nothing special about
DEC Ada, but much time has passed).

>  [snipped]
> 
>> 
>> Regardless of how you access SYS$ENQ, it is important to realize that
>> it doesn't have much regard for processes.  You can deadlock a single
>> process against itself or a single task against itself with the same
>> ease with which you deadlock two processes in deadly embrace.  The
>> crucial element of VMS locking is the Lock ID returned by SYS$ENQ[W].
>> 
> Let me pose my question another way, then, to see if I understand you.
> Assume the tasks comprising an application reference the controlled
> resource by a common name, use the proper Lock ID, and otherwise play by
> the VMS Lock Manager's rules. If Task A queues an "exclusive" lock on the
> controlled resource, does it necessarily follow Tasks B, C, D ... are
> prevented from accessing (poor choice of words?) that resource until Task A
> releases its lock, or does the Ada RTL not support VMS locking between
> tasks? Forgive me if I'm being overly obtuse, but this is the point I was
> trying to get to :)

I am not sure I fully understand the situation still, but if an
"exclusive" lock is taken out on resource R, resulting in Lock ID X,
no other (non-null) lock on resource R will be granted and no null
Locks (Lock IDs Y and Z) will be promoted above null until such time
as Lock ID X is demoted or dequeued.

This is independent of Ada task affiliation, and one would
have no problem enqueueing from Task A to produce Lock ID X and
then dequeueing that Lock ID from Task B of the same process. It
should be no different with Kernel Threads on Alpha.

But if you choose to manage your Lock Manager usage such that
Tasks A, B, C and D each enqueue for their own Lock ID and do
not share them (as is typical with most designs), the fact that
subsequent Enqueue calls will not be granted until the exclusive
holder Lock ID is demoted or dequeued effectively means that
Tasks B, C, and D will not get the lock until Task A has
demoted or dequeued its Lock ID.  The affiliation between
Tasks and Lock IDs, however, is totally under your control.

If that does not provide sufficient control, one can always
consider the 4 locking modes between Null and Exclusive, but
I can never do that without the magic diagram in front of me :-)

Larry Kilgallen