Alvaro Herrera wrote: > ipig wrote: > > Hi, > > Thanks for your reply. > > I changed the format to plain text. > > > > For the question, suppose that process p0 held the lock of object A, > > and the wait queue for A is p1,p2,p3,...., that process p1 is the first > > waiter in the queue. > > Since p1 is in the wait queue, the lock p1 requests must be conflict > > with the lock p0 held. > > That is to say, if p0 wants to lock A again, then p0 will be put before > > p1, and p0 will be at the head of the queue. Why do we need to find the > > first waiter which conflicts p0? I think that p0 must be added at the head > > of the wait queue. > > > > For your example, p0 has a read lock and wants an exclusive lock. > > Since p0 has a read lock, then in the queue, p1 must wait an exclusive > > lock. > > Then p0 will be put before p1, and p0 will be at the head of the queue. > > > > Is there anything I misunderstood? > > You missed this: > > "Note that a process never conflicts with itself, eg one can obtain read > lock when one already holds exclusive lock." > > If p0 is holding a read lock and wants an exclusive lock, it will be > granted right away. It will not be put in the waiting queue.
Uh, unless other processes also hold a read lock on the object. In that case, p0 has to wait, and I think the description is saying p0 will be put ahead of other readers waiting for the object. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
