Tom Lane <tgl@sss.pgh.pa.us> writes:
> Alfred Perlstein <bright@wintelcom.net> writes:
> >> definitely need before considering this is to replace the existing
> >> spinlock mechanism with something more efficient.
>
> > What sort of problems are you seeing with the spinlock code?
>
> It's great as long as you never block, but it sucks for making things
> wait, because the wait interval will be some multiple of 10 msec rather
> than just the time till the lock comes free.
Plus, using select() for the timeout is putting you into the kernel
multiple times in a short period, and causing a reschedule everytime,
which is a big lose. This was discussed in the linux-kernel thread
that was referred to a few days ago.
> We've speculated about using Posix semaphores instead, on platforms
> where those are available. I think Bruce was concerned about the
> possible overhead of pulling in a whole thread-support library just to
> get semaphores, however.
Are Posix semaphores faster by definition than SysV semaphores (which
are described as "slow" in the source comments)? I can't see how
they'd be much faster unless locking/unlocking an uncontended
semaphore avoids a system call, in which case you might run into the
same problems with userland backoff...
Just looked, and on Linux pthreads and POSIX semaphores are both
already in the C library. Unfortunately, the Linux C library doesn't
support the PROCESS_SHARED attribute for either pthreads mutexes or
POSIX semaphores. Grumble. What's the point then?
Just some ignorant ramblings, thanks for listening...
-Doug