This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |