Re: Thread specific data for GLib

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi, Owen

> > > The question, though, is how to provide a convenient
> > > interface to getting a unique thread index to use
> > > for your a bit of static data, without requiring
> > > locking on each fetch of the static data.
> >
> > That simply is not possible without magic (like constructors and the
> > like). Period. (Regarding pthread_once see below)
> 
> Not so fast. If you preallocate a single TSD key in
> g_thread_init(), it is possible to have thread-specific
> data that:
> 
>  1) Does not need to lock a mutex for either get or set.
>  2) Is completely portable, assuming that there is
>     some integral type that is read/written atomically.
>  3) Is quite convenient to use.
> 
> The interface is:
> 
> static guint myindex = 0;
> 
>   setspecific_once (&myindex, avalue);
>   [...]
>   somevalue = getspecific_once (&myindex);
> 
> Implementation below. The extension to
> setspecific_once (guint *, GDestroyNotify) is
> straightforward; it could be made prettier
> with a few typedefs/#define's

yes, really not bad, I actually didn't think about something along those
lines. in german we say: "gebranntes kind scheut das feuer" (burned child
avoids the fire), because it really looks like the other rejected case,
but it really is different. nifty. 
 
> [
>   You could also use the same basic strategy to build
>   a non-locking version of your GStaticMutex, but
>   I'm not convinced yet that the constructor
>   functionality is worth the complexity
> ]

I would like the constructor thingy, but it might not be necessary. OTOH
it's not really more complicated than without, one argument, one
comparison

> > > Netscape generally uses constructors to set up the
> > > the TSD indices; using pthreads you can use
> > > pthread_once().
> >
> > here is a small test, I've done:
> > pthread_mutex need 1031 nanoseconds for enter/exit pair.
> > pthread_once needs 1327 nanoseconds for call.
> > pthread_getspecific needs 3253 nanoseconds for call.
> > pthread_setspecific needs 467 nanoseconds for call.
> >
> > The program is attached for anyone to try it on his/her platform. I 
> > really
> > think, its rediculous, that pthread_setspecific is more than 5 times
> > faster than pthread_getspecific, and still more than twice as fast as a
> > pthread_mutex enter/exit pair. as you see pthread_once is slower than a
> > pthread_mutex enter/exit pair. The last should actually also hold true 
> > on
> > linux, I suppose.
> 
> I think it is ridiculous that Sun can't write a decent thread
> library ;-) On LinuxThreads, the numbers are:

yes, certainly...

> pthread_mutex need 382 nanoseconds for enter/exit pair.
> pthread_once needs 96 nanoseconds for call.
> pthread_getspecific needs 120 nanoseconds for call.
> pthread_setspecific needs 152 nanoseconds for call.

looks better, actually. ;-)
 
> [ glibc-2.0.7, PII/300, but the relative timings hold on
>   slower machines ]
> 
> pthread_once uses the double-checking idiom that
> we rejected as being not necessarily portable -
> so it's possible that Solaris is always locking
> a mutex in its implementation of pthread_once().

linux might know, that all hardware it runs on, has hardware cache
coherence, so thats should be ok. we don't know for glib, though (I know,
now news for you, just for the files)
 
> But the LinuxThreads numbers for get/setspecific
> I think should be typical for a decent package
> as compared to locking a mutex.

not nessecarily, but getspecific without mutex lock is always faster than
getspecific with it anyway ;-)
 
> for comparison, my getspecific_once and setspecific_once
> functions take 155 and 205 nanoseconds/call
> respectively... so getspecific_once should be (on LinuxThreads)
> at least 4 times as fast as your StaticMutex
> implementation.

yes, undoubtly.

[snip]

should I integrate your code into mine and make a new submission tomorrow,
or how will we proceed....

Bye,
Sebastian
-- 
+--------------============####################============--------------+
| Sebastian Wilhelmi, Institute for Computer Design and Fault Tolerance, |
| University of Karlsruhe;  Building 20.20, Room 263,  D-76128 Karlsruhe |
| mail: wilhelmi@ira.uka.de;  fax: +49 721 370455;  fon: +49 721 6084353 |
+-----------------> http://goethe.ira.uka.de/~wilhelmi <-----------------+