No Subject

[Tony Reix <Tony.Reix@Bull.Net>]

To: peter@mysql.com
Subject: Re: [Fwd: [Fwd: (POSIX Threads) NPTL Trace Tool .]]
Cc: Laetitia.Kameni-Djinou@Bull.Net, griessen@ensisun.imag.fr,
        castetm@ensisun.imag.fr, Tony.Reix@frec.bull.fr,
        Sebastien.Decugis@Ext.Bull.Net


{ From peter@mysql.com  Fri Dec 10 09:18:50 2004
{ Subject: [Fwd: [Fwd: (POSIX Threads) NPTL Trace Tool .]]
{ From: Peter Zaitsev <peter@mysql.com>

Hi peter,

{ I'm wondering what exactly are you trying to do in the trace tool to
{ find if we can get anything out of it for MySQL development and QA :)

Our goal is to provide a tool for 3 kinds of users:
a) developers/porters of multi-threaded applications
    Provide a way to see what's happening about threads inside the application.
    Possible extensions (in the future) could inform the developer if his application
    is POSIX compliant or not, and where. It could also provide an exact measure
    of contention, and say which threads are involved.
b) support teams
    Customers in China may produce a trace that will be analyzed in Oregon.
    No need for spending days for building a simpler environment showing the problem.
c) glibc/NPTL maintainers
    By looking to the trace, a glibc/NPTL expert could quickly say if the problem is
    	in the application, in NPTL or in the kernel.

This tool must have a very light impact to how the application runs. I mean
that slowing down a multi-threaded application may completely change the order
threads are executed (and sometimes the result ...). So, a bug that appears
at full speed on a multi-CPU machine may vanish if you use a heavy trace tool.


{ If you speak about simple logging of the thread API calls, there is
{ "valgrind" tool which can do so. Is there anything a lot different ?

The Valgrind documentation about their Support for POSIX threads:
	http://developer.kde.org/~sewardj/docs-2.2.0/coregrind_core.html#pthreads
clearly says that it replaces the native library (using kernel threads: 1:1) by their
own M:1 thread library which executes on 1 CPU with their own round-robin user-space
scheduler. So they change everything (and probably they add their own bugs and their
own way to implement the so-complex POSIX Threads standard).
This may be useful for modifying the way the application runs and thus find new bugs,
but it does not help at all for finding bugs that occur only with many CPUs or for
finding/understanding bugs in NPTL or in the kernel.

Also, it seems that only a sub-set of applications (or only stable versions) does work
well with Valgrind.

Since we simply add some lite-weight trace points into the source code of NPTL
(observing all the restrictive rules of POSIX Threads standard, like canceling points),
we only modify (a few) the time needed for NPTL routines to be executed. We do not change
the semantic provided by NPTL.
About the time required for tracing, and the impact to the sequence of execution of threads,
we think we are using an efficient architecture and we plan to spend more time in 2005
measuring and reducing the performance impact of our tracing tool.

We provide traces about the thread API calls, for developer needs, but also traces
about internal objects used by NPTL. In several cases, knowing how NPTL runs does help
to understand user-level bugs.
Providing a way for tracing internals of NPTL will speed up its improvement.

We plan to connect the trace tool with a GUI (Paje') dedicated to display traces of
multi-threaded applications. Thus it should help for analyzing the relation-ship between
threads, mutexes, cond-vars, semaphores, ...


I cannot imagine such a complex tool like NPTL being delivered without a trace mechanism.
Too many critical applications are now built with a multi-threaded architecture.


We would really appreciated to receive requirements about which features would help a
developer using a complex multi-threaded application.
Let me know if you would be interested as a beta-tester (and say us what your constraints:
kernel/gcc version, ...).


Cordialement/Regards,

Tony Reix
                            Carpe Diem

**********************************************************************************
Name/Company:	Tony Reix                   Bull SA - AIX/Linux R&D
EMail:		Tony.Reix@bull.net (From IBM Unix mailers: Tony.Reix@frec.bull.fr)
Position:	System Management/Java Architect - POSIX Threads - NFSv4
Web-Sites:	http://www.bull.com         http://nptl.bullopensource.org/
Address:	BULL, 1 rue de Provence, BP 208, 38432 Echirolles Cedex, France
Phone		France: 04 76 29 72 67      International: 33 4 76 29 72 67
Fax:		France: 04 76 29 76 00      International: 33 4 76 29 76 00
Bull:		Phone: 229-7267   MailAddress: FREC B1-188   Office: B1-225
**********************************************************************************
------------- End Forwarded Message -------------
Liste de diffusion nptl
Pour se désinscrire : mailto:nptl_request@bullopensource.org?subject=unsubscribe