> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > New TODO entries are:
> > * Add queue of backends waiting for spinlock
>
> I already see:
>
> * Create spinlock sleepers queue so everyone doesn't wake up at once
That is an old copy of the TODO. I reworded it. You will only see this
now:
* Improve spinlock code, perhaps with OS semaphores, sleeper queue, or spining to obtain lock on multi-cpu systems
> BTW, I agree with Vadim's opinion that we should add a new type of lock
> (intermediate between spinlocks and lockmanager locks) rather than try
> to add new semantics onto spinlocks. For example, it'd be very nice to
> distinguish read-only and read-write access in this new kind of lock,
> but we can't expect spinlocks to be able to do that.
Yes, I agree too. On a uniprocessor machine, if I can't get the
spinlock, I want to yield the cpu, ideally for less than 10ms. On a
multi-cpu machine, if the lock is held by another CPU and that process
is running, we want to spin waiting for the lock to free. If not, we
can sleep. We basically need some more sophisticated semantics around
these locks, or move to OS semaphores.
In fact, can't we sleep on an interruptible system call, and send
signals to processes when we release the lock? That way we don't have
the 10ms sleep limitation. One idea is to have a bytes for each backend
in shared memory and have each backend set the bit if it is waiting for
the semaphore. There would be no contention with multiple backends
registering their sleep at the same time.
We have seen reports of 4-cpu systems having poor performance while the
system is only 12% busy, perhaps because the processes are all sleeping
waiting for the next tick.
I think multi-cpu machines are going to give us new challenges.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026