Re: Thread safety

Re: Thread safety

[Mandar Gurav]

Hi all,

I  have created a counter (global variable in stp file) in my stp
file. I want to increment each time when some conditions are met.
I want know that, whether this particular global variable must be
protected form concurrent accesses by different instances of the same
events???

Let us take an example of cache miss. If on a multicore machine two or
more cache miss on different cores can happen simultaneously. If I am
counting those cache misses then probe functions may simultaneously
access the same variable (worst case is when they try to modify the
same variable).

So I wanted know, whether the events/ Probes are processed in
sequential manner or by different threads simultaneously.



--
|||| Mandar Gurav ||||

Re: Thread safety

[Adrien Kunysz]

[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]

On Wed, Feb 02, 2011 at 07:43:40PM +0530, Mandar Gurav wrote:
> I  have created a counter (global variable in stp file) in my stp
> file. I want to increment each time when some conditions are met.
> I want know that, whether this particular global variable must be
> protected form concurrent accesses by different instances of the same
> events???

SystemTap adds locking of global variables automatically. There are
references to that in stap(1):

   STATISTICS
       It  is  often desirable to collect statistics in a way that avoids
       the penalties of repeatedly exclusive locking the global variables
       those numbers are being put into.  Systemtap  provides  a solution
       using a special operator to accumulate values, and several
       pseudo-functions to extract the statistical aggregates.

       MAXTRYLOCK
              Maximum number of iterations to  wait  for  locks  on  global
              variables  before declaring possible deadlock and skipping
              the probe, default 1000.

And if you don't trust documentation (which is fair enough :) you can
also look at the C code SystemTap generates when you build a script like
this (with -k):

global counter

probe kernel.function("printk") {
        counter++
}

You end up with something like this:

static void probe_1820 (struct context * __restrict__ c) {
[...]
    unsigned numtrylock = 0;
    (void) numtrylock;
    while (! write_trylock (& global.s_counter_lock)&& (++numtrylock < MAXTRYLOCK))
      ndelay (TRYLOCKDELAY);
    if (unlikely (numtrylock >= MAXTRYLOCK)) {
[...]
      goto unlock_;
    }
[...]
    global.s_counter += 1;
[...]
out:
unlock_counter:
  write_unlock (& global.s_counter_lock);
unlock_: ;
  _stp_print_flush();
}

Which prevents concurrent update of the global variable.

> Let us take an example of cache miss. If on a multicore machine two or
> more cache miss on different cores can happen simultaneously. If I am
> counting those cache misses then probe functions may simultaneously
> access the same variable (worst case is when they try to modify the
> same variable).

In this specific case, I think the performance counter already exists
on most hardware and you don't even need to do any locking in software
but I am not familiar with using performance counters from SystemTap.

> So I wanted know, whether the events/ Probes are processed in
> sequential manner or by different threads simultaneously.

AFAICT, the probes are concurrent but the access to global variables
is synchronized.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Thread safety

[Frank Ch. Eigler]

mandarwce wrote:

> I have created a counter (global variable in stp file) in my stp
> file. I want to increment each time when some conditions are met.  I
> want know that, whether this particular global variable must be
> protected form concurrent accesses by different instances of the
> same events???

stap will do that for you automatically.

global foo
probe perf.BAR { foo ++ }  # exclusively locked
probe end { println (foo) }  # shared locked


> Let us take an example of cache miss. If on a multicore machine two or
> more cache miss on different cores can happen simultaneously. [...]
> So I wanted know, whether the events/ Probes are processed in
> sequential manner or by different threads simultaneously.

Concurrent operation on multiple CPUs is normal.

To make them perform best, you'll want to use aggregate types instead
of ordinary integer counters, as in:

global foo
probe perf.BAR { foo <<< 1 }  # may trigger in parallel
probe end { println (@count(foo)) }


- FChE

Re: Thread safety

[Mandar Gurav]

Ohhh! That's awesome!

But still other question.....

whether the events/ Probes are processed in sequential manner or by
different threads simultaneously?????

----Mandar Gurav

On Wed, Feb 2, 2011 at 9:53 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
>
> mandarwce wrote:
>
>> I have created a counter (global variable in stp file) in my stp
>> file. I want to increment each time when some conditions are met.  I
>> want know that, whether this particular global variable must be
>> protected form concurrent accesses by different instances of the
>> same events???
>
> stap will do that for you automatically.
>
> global foo
> probe perf.BAR { foo ++ }  # exclusively locked
> probe end { println (foo) }  # shared locked
>
>
>> Let us take an example of cache miss. If on a multicore machine two or
>> more cache miss on different cores can happen simultaneously. [...]
>> So I wanted know, whether the events/ Probes are processed in
>> sequential manner or by different threads simultaneously.
>
> Concurrent operation on multiple CPUs is normal.
>
> To make them perform best, you'll want to use aggregate types instead
> of ordinary integer counters, as in:
>
> global foo
> probe perf.BAR { foo <<< 1 }  # may trigger in parallel
> probe end { println (@count(foo)) }
>
>
> - FChE
>



-- 
|||| Mandar Gurav ||||

Re: Thread safety

[Frank Ch. Eigler]

mandarwce wrote:

> [...]
> whether the events/ Probes are processed in sequential manner or by
> different threads simultaneously?????

systemtap does not work on the same model as perf.  There is no
enqueuing of events for later handling by userspace or anything.  As
events occur, they are handled immediately by the CPU that encountered
the event.  So pmc hardware events that occur on different CPUs get
handled by the affected CPUs simultaneously.

- FChE