Re: some question about deadlock

Hi,

an exception: if the process already holds locks on this same lockable
object that conflict with the request of any pending waiter, then the
process will be inserted in the wait queue just ahead of the first such
waiter.

From the exception, I got that the process must be added at the head, since the first waiter in the queue must conflict with the lock-held process.

Best wishes.

----- Original Message -----
From: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "ipig" <ipig(at)ercist(dot)iscas(dot)ac(dot)cn>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Sent: Monday, May 29, 2006 11:26 PM
Subject: Re: [HACKERS] some question about deadlock

> 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?
>
> I am guessing that p0 is put at the head _only_ if there are conflicting
> locks so that p0 does not starve other waiting processes.
>
> --
> Bruce Momjian http://candle.pha.pa.us
> EnterpriseDB http://www.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +