Re: Instrumenting multithreaded applications

"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

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