Re: Instrumenting multithreaded applications

"Ira Baxter" <idbaxter@semdesigns.com>
26 Jan 2003 16:32:13 -0500

          From comp.compilers

Related articles
[3 earlier articles]
Re: Instrumenting multithreaded applications jstracke@speakeasy.net (John Stracke) (2003-01-25)
Re: Instrumenting multithreaded applications bobduff@World.std.com (Robert A Duff) (2003-01-25)
Re: Instrumenting multithreaded applications bje@redhat.com (Ben Elliston) (2003-01-25)
Re: Instrumenting multithreaded applications joachim_d@gmx.de (Joachim Durchholz) (2003-01-25)
Re: Instrumenting multithreaded applications chase@world.std.com (David Chase) (2003-01-25)
Re: Instrumenting multithreaded applications lex@cc.gatech.edu (Lex Spoon) (2003-01-25)
Re: Instrumenting multithreaded applications idbaxter@semdesigns.com (Ira Baxter) (2003-01-26)
| List of all articles for this month |

From: "Ira Baxter" <idbaxter@semdesigns.com>
Newsgroups: comp.compilers
Date: 26 Jan 2003 16:32:13 -0500
Organization: Compilers Central
References: 03-01-118 03-01-132
Keywords: parallel, debug
Posted-Date: 26 Jan 2003 16:32:12 EST

"Robert A Duff" <bobduff@World.std.com> wrote in message
> Matthew Legendre <legendre@u.arizona.edu> writes:
>
> > We've got a situation where we want to insert instrumentation into a
> > multithreaded application (for profiling purposes). We need to use some
> > form of mutual exclusion since the instrumentation writes to a global
> > data structure.
>
> Why not keep a separate data structure for each thread, and for each
> interrupt handler? Then the instrumentation code can write upon the
> data structure with no locking. (That seems better anyway, since it
> will perturb the timing results less than a locking implementation.)
> Then merge the data structures "later" -- at the end of the program,
> or write them out separately and merge them in a separate program.


An extreme version of this is to keep a separate data structure for
each instrumentation point (unless your signal handlers call the code
that might be writing instrumentation), and write the data there.
That might seem expensive, but if all you are doing is incrementing a
counter or adding to an elapsed time accumulator, you can do that
safely if the underlying memory is reasonably coherent simply because
none of the data is shared. At the end of the program, write all that
data out as Duff suggested.


If the signal handlers can call other code that might be running when
the signal occurs, using an atomic add-to-memory will still suffice.


A simple mechanism for adding arbitrary instrumentation-per-probe
point can be found at
http://www.semdesigns.com/Company/Publications/TestCoverage.pdf
--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.