Re: STC for libapr1 failure

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Aug 26 09:04, Ryan Johnson wrote:
> On 26/08/2011 7:15 AM, Corinna Vinschen wrote:
> >A lock on a file is represented by an event object.  Process A holds the
> >lock corresponding with event a.  Process B tries to lock, but the lock
> >of process A blocks that.  So B now waits for event a, until it gets
> >signalled.  Now A unlocks, thus signalling event a and closing the handle
> >afterwards.  But A's time slice isn't up yet, so it tries again to lock
> >the file, before B returned from the wait for a.  And here a wrong
> >condition fails to recognize the situation.  It finds the event object,
> >but since it's recognized as "that's me", it doesn't treat the event as
> >a blocking factor.  This in turn is the allowance to create its own lock
> >event object.  However, the object still exists, since b has still an
> >open handle to it.  So creating the event fails, and rightfully so.
> >
> >What I don't have is an idea how to fix this problem correctly.  I have
> >to think about that.  Stay tuned.
> If I understand correctly, the file locking protocol is to create an
> event having the same name as the file, in the same directory as
> that file, and use that to synchronize locks on the file? And the
> problem arises if a process releases the lock, signals waiting
> processes, then immediately declares victory and closes the event
> handle because the lock is now "free" ?

It's more complicated.  Have a look into flock.cc.  The code which
handles locks on a file are guarded by a file-specific mutex.  The locks
themsleves are represented by an event object which name is supposed to
identify a given lock.  Blocking locks for a given scenario are fetched
by enumerating the given lock objects for a file and then testing if
any one of them results in a blocking condition.  The problem here is
that process A doesn't know anymore that it has hold the lock at one
point and tries to create the exact same event again.

But the overall situation is more complicated, especially in the case of
BSD flock locks due to their semantics.  It loooks like I have to add a
per-lock mutex to the whole thing and abandon some really dump assumptions
I made at one point...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat