This is the mail archive of the libc-hacker@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gprof and LinuxThreads


> 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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]