Re: [HACKERS] Lock freeze ? in MVCC

> Do you say about the following stuff in ProcSleep() ?
>
> proc = (PROC *) MAKE_PTR(waitQueue->links.prev);
>
> /* If we are a reader, and they are writers, skip past them */
> for (i = 0; i < waitQueue->size && proc->prio > prio; i++)
> proc = (PROC *) MAKE_PTR(proc->links.prev);
>
> /* The rest of the queue is FIFO, with readers first, writers last */
> for (; i < waitQueue->size && proc->prio <= prio; i++)
> proc = (PROC *) MAKE_PTR(proc->links.prev);
>
> Seems above logic is only for 2 levels of priority(READ/WRITE).
> But it's difficult for me to propose a different design for this.

I think this is a classic priority inversion problem. If the process
holds a lock and is going for another, but their is a higher priority
process waiting for the lock, we have to consider that if we go to
sleep, all people waiting on the lock will have to wait for me to
complete in that queue, so we can either never have a process that
already holds any lock from being superceeded by a higher-priority
sleeping process, or we need to check the priority of all processes
waiting on _our_ locks and check when pulling stuff out of the lock
queue because someone of high priority could come while I am in the
queue waiting.

My recommendation is to not have this go-to-end of queue if there is
someone higher if I already hold _any_ kind of lock. I can easily make
that change if others agree.

It makes the code your are questioning active ONLY if I already don't
have some kind of lock. This may be the most efficient way to do
things, and may not lock things up like you have seen.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026