[libdispatch-dev] trivial linux patch + general questions

Joakim Johansson jocke at tbricks.com
Mon Apr 18 00:08:29 PDT 2011

On Sat, 16 Apr 2011 22:34:21 +0700
  "C. Bergström" <cbergstrom at pathscale.com> wrote:
>Does anyone have ideas on Solaris or Linux non-portable 
>tsd or semaphore optimizations? Thanks! ./C

Some small comment with regard to TSD optimization for Linux/Solaris 
(I did have a small look at this for Solaris):

I'm not aware of how it looks at Linux, but Solaris do already have a 
quite optimized version of pthread_get/set_specific() for the first 8 
TSD keys allocated [1]. For most "normal" applications, the 
libdispatch keys would be allocated in that space during startup 
during library initialization. See links below for details (it is not 
much code to read really...).

Of course, the Apple implementation is even one more notch 'down to 
the metal' [2] - for Solaris I could see the following possible 

1. Use the non-portable thr_get/set_specific instead of the pthread 
interface, it saves one function call when setting TSD, but loses one 
load/store for the get interface
2. Inline the appropriate logic similar to the Apple TSD optimization 
using the knowledge of the libc implementation from opensolaris.org

"1" Seems like easy and "safe", but will trade off slightly worse 
performance for TSD lookup (see comments in the link below) vs 
avoiding an extra function call when setting a TSD - depends on the 
usage pattern of libdispatch - I think this has a decent chance of 
being a net loss in reality…

"2" Would in practice be difficult to do in terms of robustness 
(Oracle might change the implementation…), but could fairly easily be 
done as a proof-of-concept just for testing the performance difference 
by peeking at the implementation referenced below. It might be a small 
challenge to get the required interfaces supported directly by Oracle 
then as the next step :-)

Frankly, I don't think either one is that attractive unless someone 
from Oracle/Sun would like to step in and directly address "2" so it 
could be done in a supported way.

A good performance test case would be needed before going either route 
though, so far I haven't seen either function in any samples on 
Solaris and decided to postpone further investigation until it's 
popped up in any samples.






Getting current thread ("curthread", from thr_uberdata.h):



More information about the libdispatch-dev mailing list