|Instrumenting multithreaded applications firstname.lastname@example.org (Matthew Legendre) (2003-01-21)|
|Re: Instrumenting multithreaded applications email@example.com (2003-01-25)|
|Re: Instrumenting multithreaded applications firstname.lastname@example.org (Dmitry A.Kazakov) (2003-01-25)|
|Re: Instrumenting multithreaded applications email@example.com (John Stracke) (2003-01-25)|
|Re: Instrumenting multithreaded applications bobduff@World.std.com (Robert A Duff) (2003-01-25)|
|Re: Instrumenting multithreaded applications firstname.lastname@example.org (Ben Elliston) (2003-01-25)|
|Re: Instrumenting multithreaded applications email@example.com (Joachim Durchholz) (2003-01-25)|
|[3 later articles]|
|From:||Matthew Legendre <firstname.lastname@example.org>|
|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
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
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.
Return to the
Search the comp.compilers archives again.