This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Thread safety
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Mandar Gurav <mandarwce at gmail dot com>
- Cc: systemtap at sourceware dot org
- Date: Wed, 02 Feb 2011 11:23:28 -0500
- Subject: Re: Thread safety
- References: <AANLkTi=QZcCzvfh7rKOODPXc2H9pi4xOM5BF+0eOcTQj@mail.gmail.com> <AANLkTinJKhqEtGnpysHL0j4hwi+pCZniB8VDGMf67CUx@mail.gmail.com>
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