Re: Instrumenting multithreaded applications

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


>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.


What you need from the underlying threading package is only thread
identification. If you have thread ID you can track down lock owner to
avoid deadlocks.


However it is generally a bad idea to hold a lock for a long period of
time. A better approach could be rendezvous (as in Ada) with some
dedicated thread or a queue to the thread. In the latter case lock is
taken only to put a message into the queue. Alternatively, you can
consider splitting your protected operation into two (or more) each
protected by its own lock, so that a thread would take first the
lock1, then the lock2 etc.


---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

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