This is the mail archive of the
libc-hacker@cygnus.com
mailing list for the glibc project.
Re: gprof and LinuxThreads
- To: Xavier.Leroy@inria.fr
- Subject: Re: gprof and LinuxThreads
- From: Geoff Keating <geoffk@ozemail.com.au>
- Date: Thu, 14 Jan 1999 21:28:42 +1100
- CC: libc-hacker@cygnus.com
- References: <19990113130630.03592@pauillac.inria.fr>
> Date: Wed, 13 Jan 1999 13:06:30 +0100
> From: Xavier Leroy <Xavier.Leroy@inria.fr>
>
> Dear all,
>
> I have exchanged mail with some users about gprof(1) profiling of
> multi-threaded programs under LinuxThreads. The conclusions so far
> are as follows:
>
> 1- Each thread needs to do "moncontrol(1);" at start-up in order
> to activate PC sampling for that thread. This could easily be done
> in a profiling version of libpthread (libpthread_p.a ?)
Better, surely, to do it in the usual libpthread library, because that
way people don't have to have huge binaries just to profile their
executables.
> 2- PC sampling as implemented in sysdeps/posix/profil.c seems mostly
> thread-safe. One could argue that the increment in profil_count
>
> if (i < nsamples)
> ++samples[i];
>
> should be made atomic (using the <atomicity.h> macros), although
> PC-sampling is statistical in nature and might tolerate occasional
> lost increments due to race conditions.
It's not unlikely that on a fast machine, all the sampling will happen
at the same time; all that would be required is for all threads to
start inside the same tick. This could produce wrong results if the
code spends much time inside some small inner loop (as code tends to
do).
Still, as you say it's easy enough to fix.
Should the libc be exporting <atomicity.h>? It seems like the sort of
thing that user programs might find useful...
--
Geoffrey Keating <geoffk@ozemail.com.au>