Re: VAX Ada Tasks and VMS Lock Manager

Re: VAX Ada Tasks and VMS Lock Manager

[Larry Kilgallen]

In article <01bc9579$39aaaf40$83ecced0@jpeterson>, "Jay and Cathy Peterson" <JPeterson@PCBYTE.net> writes:

> 	I am currently debugging a VAX Ada (v1.5, if it makes a difference)

They are well beyond V1.5 now, fixing many bugs, so it may matter to you.

> application which contains roughly four tasks (plus the main task); one of
> which is is used to synchronize access to a file. Additionally, I am using
> the VMS Lock Manager (VMS version 5.4-2 -- I know; but it is what I have to

They are well beyond V5.4-2 now, fixing many bugs, so it may matter to you.

> work with) to assure the tasks don't walk over pertinent data; namely file
> pointers I include in the controlled-access file. All of that to get to my
> question: How do VAX Ada and VMS treat tasks for locking purposes? The
> "traditional" use of SYS$ENQ and SYS$DEQ are to synchronize processes, I
> know. If I issue a TASKING_ENQW, are the other tasks locked out, or do I

The TASKING_ENQW would be the same as any other TASKING_* jacket for the
"Wait" form of a system service -- other Ada tasks will be allowed to
proceed.

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].

> need find another way of keeping the tasks from walking on each other? The
> VAX Ada documentation at my disposal is silent on this issue, as far as I
> can ascertain. Any insight into this situation would be appreciated. 

They are well beyond V1.5 now, augmenting the documentation, so maybe
it did matter to you :-).

You might do better with the current documentation, even if you have
the older software.

Regards,
Larry Kilgallen

Re: VAX Ada Tasks and VMS Lock Manager

[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

Re: VAX Ada Tasks and VMS Lock Manager

[Jay and Cathy Peterson]

Larry Kilgallen <kilgallen@eisner.decus.org> wrote in article
<1997Jul22.070236.1@eisner>...
> In article <01bc965a$b5135f60$88ecced0@jpeterson>, "Jay and Cathy
Peterson" <JPeterson@PCBYTE.net> writes:

[snipped]
> 
> 
> 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.
> 
That answered my question; thank you for taking time to respond :)

Jay Peterson

Re: VAX Ada Tasks and VMS Lock Manager

[Jay and Cathy Peterson]

Larry Kilgallen <kilgallen@eisner.decus.org> wrote in article
<1997Jul21.101731.1@eisner>...
> In article <01bc9579$39aaaf40$83ecced0@jpeterson>, "Jay and Cathy
Peterson" <JPeterson@PCBYTE.net> writes:
> 
> > 	I am currently debugging a VAX Ada (v1.5, if it makes a difference)
> 
> They are well beyond V1.5 now, fixing many bugs, so it may matter to you.
> 
> > application which contains roughly four tasks (plus the main task); one
of
> > which is is used to synchronize access to a file. Additionally, I am
using
> > the VMS Lock Manager (VMS version 5.4-2 -- I know; but it is what I
have to
> 
> They are well beyond V5.4-2 now, fixing many bugs, so it may matter to
you.
> 
First, thank you for your response to my query; I appreciate it. 
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 :)
 
 [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 :)

[snipped]

> 
> You might do better with the current documentation, even if you have
> the older software.
> 
> Regards,
> Larry Kilgallen
> 
Thank you again for your help,
J. A. Peterson