Re: [PERFORM] futex results with dbt-3

[Manfred Spraul]

Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
              http://www.postgresql.org/docs/faqs/FAQ.html