missing multiple blocking ASTs
Filip De Block
Process #1 takes a lock on a give resource :
1. $ENQ for this resource with NL (granted immediately)
2. $ENQ (convert) to EX, specifying BLKAST
3. goto hibernate
Process #2 (same UIC, same cluster) tries to do the same :
1. $ENQ for same resource with NL (granted immediately)
2. $ENQ (convert) to EX, specifying BLKAST
The lock is not granted (immediately), but as expected, the BLKAST
is triggered in PRC #1
PRC#1 decides (inside its BLKAST that is now active) to keep the lock
for itself and do nothing. This leaves us with the second 'lock
conversion request' on the conversion queue.
After some time, PRC #2 decides to die, since it cannot get the lock,
hereby removing the usermode lock from the conversion queue, as can be
seen by SDA.
A new process is created (PRC #2bis) that does exactly the same thing
:
requesting an EX lock (via conversion) on the same resource.
But this time the blocking AST for PRC #1 is not fired, and hence PRC
#1 does not know about a competitor.
Anyone an idea how to get this working ?
advTHANKSance
John Vottero
news:8366afbe.03072...@posting.google.com...
Process #1 must convert the lock from EX to EX to reset the blocking AST.
John Gemignani, Jr.
"John Vottero" <Jo...@mvpsi.com> wrote in message
news:vhqmc39...@news.supernews.com...
You only get one blocking AST per conversion. If you convert the lock down
to something compatible with the other process (NL always works) then back
up to EX, the second locker will get the lock, receive a blocking AST (if it
set one), release the lock (I hope), and your conversion back to EX will
obtain it again.
Are you using the lock to pass state/context information (via the value
block) or to synchronize access to something?
Filip De Block
1. Converting to itself (from EX to EX), hereby reestablishing the
BLKAST :
no good, since it starts looping (in and out the BLKAST) because PRC
#2 still has its request queued for NL-->EX. (Killing #2 stops the
looping)
2. Converting to NL (so #2 gets the lock) and then back to EX (so #2
triggers the BLKAST) will start a looping sequence between two (or
ever more !) processes. Still not usable.
The purpose of this exercise is to have 100% indentical processes
(clusterwide) that can distribute a given number of 'resources' among
themselves, regardless of te number of processes. Still a long way to
go ...
Bob Koehler
>
> 1. Converting to itself (from EX to EX), hereby reestablishing the
> BLKAST :
> no good, since it starts looping (in and out the BLKAST) because PRC
> #2 still has its request queued for NL-->EX. (Killing #2 stops the
> looping)
>
> 2. Converting to NL (so #2 gets the lock) and then back to EX (so #2
> triggers the BLKAST) will start a looping sequence between two (or
> ever more !) processes. Still not usable.
>
> The purpose of this exercise is to have 100% indentical processes
> (clusterwide) that can distribute a given number of 'resources' among
> themselves, regardless of te number of processes. Still a long way to
> go ...
Sounds like you need to rethink you're locking design.
What is the purpose of having a blocking AST if process #1 isn't going
to give up the lock? Is this conditional?
I think you need some mechanism (a doorbell lock would suffice) for
process #1 to tell process #2 it can't have the original lock, and
should go away. Then process #2 should cancel it's enque and inform
process #1 that it's OK to reestablish the blocking AST. But you need
to work out a complete and proper design without the flaw I just
thought of.
John Vottero
If that's the purpose, why do you need a blocking AST? If the holder of a
resource needs to know if there are other processes that would accept
ownership of the lock, it could call sys$getlki to see who's waiting for the
resource.
Joshua Lehrer
>
> The purpose of this exercise is to have 100% indentical processes
> (clusterwide) that can distribute a given number of 'resources' among
> themselves, regardless of te number of processes. Still a long way to
> go ...
I had this exact same task about a year back.
My solution was complex, but went something like this:
You need a gateway lock and a resource lock. Consumers only get null
locks on the resource, and exclusive locks on the gateway.
The single exclusive lock controls who is next in line. Whenever
someone wants to use the resource, they take out the exclusive gateway
lock. When they get it, use the lock manager to determine how many
people have null locks on the resource. If there are too many, then
hibernate. If there aren't, get the null lock on the resource and
release the exclusive lock on the gateway.
Whenever anyone is done with the resource, they attempt to take out an
exclusive lock on the gateway, no-queue. If they happen to get it,
just release it. The person who was waiting having had the gateway
lock gets their blocking ast called and wakes up from hibernation. It
can then check the lock information, get the null lock on the
resource, and release the exclusive lock on the gateway.
Of course, there are minor issues that you need to deal with wrt race
conditions, crashing processes, etc... But this was the general idea.
Wrap it all up in a nice C++ class, and you've got a very useful
cluster-wide gate!
-joshua lehrer
factset research systems