STC for libapr1 failure

Ryan Johnson ryan.johnson@cs.utoronto.ca
Fri Aug 26 13:18:00 GMT 2011


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" ?

Nasty problem. Comes up with database locking implementations as well: 
how to know when it's safe to garbage collect a lock's storage, when the 
synchronization primitive that would normally tell you is embedded in 
that same storage...

The simplest solution I've come up with so far is to keep around a set 
of permanent mutex locks, and assign every (file/database) lock to one 
mutex, e.g. by hashing. Then, locks can only be created or destroyed by 
a process holding the owner lock, which eliminates the race window where 
we know the lock is free but don't know whether its storage is still 
valid. Normally 4-8 mutex locks is plenty to avoid bottlenecks.

Thoughts?
Ryan



More information about the Cygwin-developers mailing list