[Info-vax] missing multiple blocking ASTs

[John Gemignani, Jr.]

"Pierre" <pierre.bru at gmail.com> wrote in message 
news:dfa8f08c-6562-40a6-b48f-e8a32e5d676b at y1g2000pra.googlegroups.com...
> this is a continuation of this old thread
> http://groups.google.com/group/comp.os.vms/browse_thread/thread/56e0231ee2572aa8/000979f21f192ffa
>
> On Jul 24 2003, 7:21 am, usenet_... at lehrerfamily.com (Joshua Lehrer)
> wrote:
>>
>> 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.
>
> but if a process is waiting (hibernated) and another one wants to get
> access to the resource, the second process will trigger the blocking
> AST. as a blocking AST can be triggered only once, the waiting process
> has to find a way to re-arm its blocking AST. or is this the race
> conditions you are talking below ?
>
>> Of course, there are minor issues that you need to deal with wrt race
>> conditions, crashing processes, etc... But this was the general idea.
>
> could you please elaborate on race conditions and crashing processes
> handling ?
>
>> Wrap it all up in a nice C++ class, and you've got a very useful
>> cluster-wide gate!
>>
>> -joshua lehrer
>> factset research systems
>
> TIA,
> Pierre.

I put together the exec mode file system code for UCX. It is true that you 
will receive one and only one
blocking AST per lock state. I also found that it was not possible to 
convert EX to EX when there is a
pending conflicting request; I was getting conflict/deadlock errors. (There 
is no way to keep the original
EX lock and seemlessly go to another EX lock without going through an 
interim lock state that would
allow the conflicting lock to be acquired.) As a result, I had to go from EX 
to NL with a completion AST.
When the completion AST fired, the AST routine reevaluated the lock and, if 
warranted, would convert the
lock to another possible state (perhaps back up to EX).

In general, the file system kept the lock in the last mode that it was used 
in. The lock protected all object
cache state and used a sequencing mechanism to record actual changes in the 
lock data area. This allowed
several special optimizations, one of which was a quick, single read to 
execute under the write lock (EX
was the write lock, PR the read lock, and NL the no-lock). A read would not 
need to update the sequence
number. (If you ever lost the sequence number [data not valid] then the 
assumption is that a modification
was made and the cache needs to be replenished.

There were also some fairness algorithms that would allow multiple writes to 
get through before releasing
the lock in the interest of reducint interlocking overhead, as many 
algorithms oftern favor multiple, concurrent
readers over a single writer.

As an FYI: four types of locks were implemented and, while they were 
conceptually hierarchical, they did
not use the lock manager's sublock capabilities as a conflicting parent lock 
would affect all sublocks and
that is a serious problem when you are extensively caching data at the 
various levels for performance.

John