Instrumenting multithreaded applications

Matthew Legendre <legendre@u.arizona.edu>
21 Jan 2003 00:14:44 -0500

          From comp.compilers

Related articles
Instrumenting multithreaded applications legendre@u.arizona.edu (Matthew Legendre) (2003-01-21)
Re: Instrumenting multithreaded applications nmm1@cus.cam.ac.uk (2003-01-25)
Re: Instrumenting multithreaded applications mailbox@dmitry-kazakov.de (Dmitry A.Kazakov) (2003-01-25)
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)
[3 later articles]
| List of all articles for this month |

From: Matthew Legendre <legendre@u.arizona.edu>
Newsgroups: comp.compilers
Date: 21 Jan 2003 00:14:44 -0500
Organization: The University of Arizona
Keywords: performance, testing, parallel
Posted-Date: 21 Jan 2003 00:14:44 EST

Does anyone have any experience with or know of any work related to
instrumenting a multithreaded application?


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.


The problem is that we may insert instrumentation into a signal handler.
So a thread may enter the instrumentation code and open the appropriate
lock. A signal then fires and transfers control to the signal handler.
The thread then re-enters the instrumentation and deadlocks on a lock it
already owns.


I've already seen a paper by people on the Paradyn project at the Univ. of
Wisconsin called 'Dynamic Instrumentation of Thread Applications' in which
they suggest creating a locking mechanism that won't let a thread block on
or enter a lock that it already has open. Unfortunately this involves
knowledge of the underlying threading package, and I'd like to avoid
opening that can of worms.


-Matthew LeGendre


Post a followup to this message

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