This is mostly an informational rant: feel free to ignore most of it. I think I have gotten down what was going on in UFS. In Savannah task 5487, Samuel wrote: > - Note the code in urfs/pager.c: it looks inside the rwlock in an ugly > way. It looks like it is just trying to wait for the read lock to be > available, but not actually lock. The part of me with OOP beaten into it agrees that the code uses the lock in an inappropriate way, but another part of me sees the elegance of the solution. In sizes.c, the code again reaches into the lock in an ugly way, and it reveals why such behavior is occurring.
There is a condition in which readers of the object that the rwlock protects can access the resource without needing to acquire the lock. The code in pager.c is a mutated trylock that allows threads to wait to either get the lock or have that condition occur. The part in sizes.c signals that the specific condition is valid to any threads waiting for the lock or condition. The attached file is a patch to the previous pthreads patch. It adds a condition and a lock to each resource object to allow the previous behavior without violating the integrity of any pthread locking primitives. The manner in which our pthread implementation handles rwlocks is so very different from how cthreads does that trying to pull the same trick isn't feasible, anyway. I think that the previous pthread code was the direct conversion to pthreads of cthreads calls that produced a similar chain of events as what the code was doing. It was trying to answer "How do I do this in pthreads?" and not "What is going on?" TD PS - Does anyone use UFS?
ufsdiff.diff
Description: Binary data
