On Sat, 15 Dec 2007 14:26:32 -0800, Keith Packard wrote: > > On Sat, 2007-12-15 at 13:34 -0800, Eric Anholt wrote: >> On Sat, 2007-12-15 at 11:07 -0700, Brian Paul wrote: >> > Keith Packard wrote: >> > > The pthreads library introduces significant overhead for single-threaded >> > > applications, >> > >> > Just out of curiosity, have you made some measurements? >> >> As keithp noted, we were seeing 5-10% CPU time in pthread mutex >> operations depending on the app being profiled on 965. It's gone with >> the dri_bufmgr pthread removal I did, but I've later realized that we >> can't just do that, since buffer objects are shared between contexts >> (ugh), so the bufmgr internals will need to be protected from concurrent >> access and those costs will be coming back. > > For ref counting, gcc has atomic inc/dec operations these days, so we > should be able to use those to limit the cost here. > > The real issue here is not in our libraries or test applications. > Consider a "real" single threaded application which happens to use > stdio. Linking in the -lpthread version of that library turns out to be > a disaster for thinks like putchar/getchar, so we're imposing cost on > all applications when we support any threaded applications, unless we > either force applications to tell us when they need locking (ala > XInitThreads), or use the weak symbol hack. >
The glibc locking primitives used by stdio and malloc are always present and are no-ops until after the first thread is created, so merely linking to libpthread won't hurt you. ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
