Message-Id: <9601200255.AA20374@jimi.MIT.EDU>
To: jha@cs.purdue.edu ("John H. Aughey")
Cc: pthreads@MIT.EDU, proven@MIT.EDU
Subject: Re: link line, SHLIB, and stats 
In-Reply-To: Your message of "Fri, 19 Jan 1996 11:17:24 EST."
             <199601191617.LAA13433@moriarty.cs.purdue.edu> 
Date: Fri, 19 Jan 1996 21:55:15 EST
From: Christopher Provenzano  <proven@MIT.EDU>


> The link line in pgcc.sh has '-lpthread -lm -lgcc -lpthread'.  Why is
> pthread linked twice?

This is because libpthread is replacing some symbols of libc and so in
libgcc, and I want to ensure that the linker always gets the symbol first
from libpthread then libgcc then libc. There is at least one case where
symbol a is defined in libpthread and libc and symbol b which uses symbol
a is defined in libgcc and libc, and symbol a is not likely to be linked
in on its own. 

( It's actually worse than what you see. There is an implicit -lgcc -lc 
after the final -lpthread if you use gcc. )

> 
> Also, I would like to suggest a shared library is compiled as well.
> Linking statically takes a long time and creates a huge binary.  I
> would much rather link dynamically and only link statically if I need
> to move the binary to a machine without the shared library.

Yes, I'm working on them. If you don't need to debug the binary you can
strip it which will reduce its size considerably.

> 
> Also, is there a way to get statistics about the threads, locks, etc?
> In particular I'd like to be able to know how much time is spent idle
> while waiting for a lock.  This would let me know if I need to rewrite
> some of my code to avoid the locks.

Not yet. I would suggest, for now, writing wrapper routines around the mutex 
routines that does this for you and saves the stats as thread specific data.

CAP