Threads and userland profliing...

[David Xu]

David Xu wrote:

> Daniel Eischen wrote:
>
>> 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.
>>
>>  
>>
> Because I never thought the profile buffer should be per-process,

OOPS,  I thought it should be per-process, not per-thread.

> did you mean that it should be per-process too?
>
> David Xu
>
>
>
>