From mboxrd@z Thu Jan  1 00:00:00 1970
From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Date: Tue, 2 Dec 2008 14:50:16 -0500
Subject: [ltt-dev] trace a futex
In-Reply-To: <8d94e9280812021142j2eb5ca72td730410e97ccd9a1@mail.gmail.com>
References: <8d94e9280812021142j2eb5ca72td730410e97ccd9a1@mail.gmail.com>
Message-ID: <20081202195015.GA25792@Krystal>

* Gian Lorenzo Meocci (glmeocci at gmail.com) wrote:
> Hi all,
> 
> I am working (always) on a multithread tracing system. I would know if
> there is a method to trace, with LTTng, an lll_lock or a lowlevel
> function futex_wait.
> I want establish if a synchronization primitive (like
> pthread_mutex_lock or sem_wait) has acquires a lock or not.

Tracing futex wait will only tell you when there has been "heavy"
contention on the mutex which required to put the process to sleep. The
pthread code starts by looping a few times actively waiting for the lock
before it calls the OS.

Therefore, the best way to trace this would be to use the userspace
markers and trace the mutex down/up events. This would imply recompiling
the pthread library.

Also note that when this instrumentation will be enabled (I mean by this
dynamically enabled at runtime), the system may be noticeably slower
because there will be 1 system call each time the mutex primitive is
called. The current userspace tracing goes through a system call to the
OS. Eventually, we should be able to change that into a direct memory
write, which will be much faster.

Mathieu

> 
> Thanks a lot,
> 
> 
> -- 
> Ing. Gian Lorenzo Meocci
> http://www.meocci.it
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68