Threads and userland profliing...

[Daniel Eischen]

On Tue, 11 May 2004, John Baldwin wrote:

> Currently in the pstats structure we have a uprof substructure that holds 
> various values used for userland processing.  Does anyone know what parts of 
> that structure are supposed to be per-process and which are supposed to be 
> per-thread?  pr_addr and pr_ticks seem to be definite per-thread items, but 
> the other values I'm not sure of.
> 
> Specifically, is the userland table that pr_base, pr_size, pr_off, and 
> pr_scale refer to per-thread or is it supposed to be shared among all threads 
> in a process?  If it's shared, do we need to be using casuptr() or something 
> similar in addupc_intr() instead of a separate fetch and store?  
> addupc_task() also has a race window between the copyin() and copyout() as 
> well if it is shared.  If its private, then I suppose each thread has to call 
> profil(2) and gprof is supposed to be smart enough to make that happen?  Does 
> POSIX have anything to say regarding threads and profil(2)?

POSIX does not define profil(2).  Here's what Solaris 9 has to
say about it:

     In Solaris releases prior to 2.6, calling profil() in a mul-
     tithreaded  program  would  impact only the calling LWP; the
     profile state was not inherited at  LWP  creation  time.  To
     profile  a  multithreaded  program  with  a  global  profile
     buffer, each thread needed to issue a call  to  profil()  at
     threads  start-up  time,  and  each thread had to be a bound
     thread. This was  cumbersome  and  did  not  easily  support
     dynamically  turning  profiling  on and off. In Solaris 2.6,
     the profil() system call  for  multithreaded  processes  has
     global  impact  -  that  is,  a call to profil() impacts all
     LWPs/threads in the process.  This  may  cause  applications
     that  depend  on the previous per-LWP semantic to break, but
     it is expected to improve multithreaded programs  that  wish
     to turn profiling on and off dynamically at runtime.

We should probably avoid the mistake that Solaris < 2.6
made.

-- 
Dan Eischen