Tom Lane wrote:
>Manfred Spraul <manfred@colorfullife.com> writes:
>
>
>>Has anyone tried to replace the whole lwlock implementation with
>>pthread_rwlock? At least for Linux with recent glibcs, pthread_rwlock is
>>implemented with futexes, i.e. we would get a fast lock handling without
>>os specific hacks.
>>
>>
>
>"At least for Linux" does not strike me as equivalent to "without
>OS-specific hacks".
>
>
>
For me, "at least for Linux" means that I have tested the patch with
Linux. I'd expect that the patch works on most recent unices
(pthread_rwlock_t is probably mandatory for Unix98 compatibility). You
and others on this mailing list have access to other systems - my patch
should be seen as a call for testers, not as a proposal for merging. I
expect that Linux is not the only OS with fast user space semaphores,
and if an OS has such objects, then the pthread_ locking functions are
hopefully implemented by using them. IMHO it's better to support the
standard function instead of trying to use the native (and OS specific)
fast semaphore functions.
>The bigger problem here is that the SMP locking bottlenecks we are
>currently seeing are *hardware* issues (AFAICT anyway). The only way
>that futexes can offer a performance win is if they have a smarter way
>of executing the basic atomic-test-and-set sequence than we do;
>
>
lwlocks operations are not a basic atomic-test-and-set sequence. They
are spinlock, several nonatomic operations, spin_unlock.
--
Manfred
