|
From: Mike L. <mik...@gm...> - 2017-06-22 18:58:27
|
Hi John, I appreciate you taking the time to comment. I agree with your
assessments and wanted to comment on a few points.
> C'mon. The tools re-use thread IDs because that is the easiest
> and most efficient way to track the running threads.
> If no re-use, then the next easiest way is to increment forever.
> Then the threadID cannot be an 'unsigned short', and there must be
> an adaptive hash table (or other non-trivial lookup mechanism)
> from threadID to internal thread structure, and the hash table
> must allow frequent deletions.
To clarify, I am not suggesting a change to make every thread hash to a
unique ID.
I was asking if there were any best-known-methods for detecting a new
thread in the Valgrind scheduler. For example, it looks like tools such as
Callgrind, rely on calling VG_(get_running_tid)() every basic block to
detect different threads. Using this method can produce misleading
information by conflating metadata from different threads.
Notably, Linux approaches PID generation by incrementing until the max ID
is reached, and then wrapping around and reusing any available IDs.
Although I don't know the internals of how the kernel achieves this, this
can be naively tracked with a 8KB bit vector for a 16-bit thread ID, .
I'm unaware of how Valgrind currently tracks thread IDs.
> Modify the source to suit yourself. You will see how
> un-worthwhile the modifications are for the existing use cases.
Again, I'm not contending for Valgrind internal changes. I would contend,
however, that being able to reliably detect when a thread starts/stops
within instrumented code is valuable.
I've seen the track_{start,stop}_client_code callbacks suggested, but I've
also seen that VG_(get_running_tid)() is supposed to be more reliable.
e.g. *http://www.mail-archive.com/val...@li.../msg03441.html
<http://www.mail-archive.com/val...@li.../msg03441.html>
*
Thank you again,
Mike
|
|
From: Philippe W. <phi...@sk...> - 2017-06-22 19:50:05
|
Helgrind maintains a unique thread nr by intercepting pthread_create,
as e.g. helgrind needs to speak about terminated threads
and so, cannot use the tid, as the tid is re-used : a new thread uses
the lowest free tid value.
See hg_main.c evh__pre_thread_ll_create, hooked up with
VG_(track_pre_thread_ll_create)( evh__pre_thread_ll_create );
so, with this, your tool might maintain an array indexed by tid
mapping to a unique thread nr for every created thread (even if
it died since then).
Philippe
On Thu, 2017-06-22 at 18:58 +0000, Mike Lui wrote:
> Hi John, I appreciate you taking the time to comment. I agree with
> your assessments and wanted to comment on a few points.
>
>
>
> > C'mon. The tools re-use thread IDs because that is the easiest
>
> > and most efficient way to track the running threads.
> > If no re-use, then the next easiest way is to increment forever.
> > Then the threadID cannot be an 'unsigned short', and there must be
> > an adaptive hash table (or other non-trivial lookup mechanism)
> > from threadID to internal thread structure, and the hash table
> > must allow frequent deletions.
>
>
> To clarify, I am not suggesting a change to make every thread hash to
> a unique ID.
> I was asking if there were any best-known-methods for detecting a new
> thread in the Valgrind scheduler. For example, it looks like tools
> such as Callgrind, rely on calling VG_(get_running_tid)() every basic
> block to detect different threads. Using this method can produce
> misleading information by conflating metadata from different threads.
>
>
> Notably, Linux approaches PID generation by incrementing until the max
> ID is reached, and then wrapping around and reusing any available IDs.
> Although I don't know the internals of how the kernel achieves this,
> this can be naively tracked with a 8KB bit vector for a 16-bit thread
> ID, .
> I'm unaware of how Valgrind currently tracks thread IDs.
>
>
> > Modify the source to suit yourself. You will see how
> > un-worthwhile the modifications are for the existing use cases.
>
>
> Again, I'm not contending for Valgrind internal changes. I would
> contend, however, that being able to reliably detect when a thread
> starts/stops within instrumented code is valuable.
>
> I've seen the track_{start,stop}_client_code callbacks suggested, but
> I've also seen that VG_(get_running_tid)() is supposed to be more
> reliable. e.g.
> http://www.mail-archive.com/val...@li.../msg03441.html
>
>
> Thank you again,
> Mike
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Mike L. <mik...@gm...> - 2017-06-23 02:21:45
|
The implementation in helgrind looks like a good way to go about this. This
is what I'm looking for.
Thanks!
Mike
On Thu, Jun 22, 2017 at 3:49 PM Philippe Waroquiers <
phi...@sk...> wrote:
> Helgrind maintains a unique thread nr by intercepting pthread_create,
> as e.g. helgrind needs to speak about terminated threads
> and so, cannot use the tid, as the tid is re-used : a new thread uses
> the lowest free tid value.
>
> See hg_main.c evh__pre_thread_ll_create, hooked up with
> VG_(track_pre_thread_ll_create)( evh__pre_thread_ll_create );
>
> so, with this, your tool might maintain an array indexed by tid
> mapping to a unique thread nr for every created thread (even if
> it died since then).
>
> Philippe
>
>
> On Thu, 2017-06-22 at 18:58 +0000, Mike Lui wrote:
> > Hi John, I appreciate you taking the time to comment. I agree with
> > your assessments and wanted to comment on a few points.
> >
> >
> >
> > > C'mon. The tools re-use thread IDs because that is the easiest
> >
> > > and most efficient way to track the running threads.
> > > If no re-use, then the next easiest way is to increment forever.
> > > Then the threadID cannot be an 'unsigned short', and there must be
> > > an adaptive hash table (or other non-trivial lookup mechanism)
> > > from threadID to internal thread structure, and the hash table
> > > must allow frequent deletions.
> >
> >
> > To clarify, I am not suggesting a change to make every thread hash to
> > a unique ID.
> > I was asking if there were any best-known-methods for detecting a new
> > thread in the Valgrind scheduler. For example, it looks like tools
> > such as Callgrind, rely on calling VG_(get_running_tid)() every basic
> > block to detect different threads. Using this method can produce
> > misleading information by conflating metadata from different threads.
> >
> >
> > Notably, Linux approaches PID generation by incrementing until the max
> > ID is reached, and then wrapping around and reusing any available IDs.
> > Although I don't know the internals of how the kernel achieves this,
> > this can be naively tracked with a 8KB bit vector for a 16-bit thread
> > ID, .
> > I'm unaware of how Valgrind currently tracks thread IDs.
> >
> >
> > > Modify the source to suit yourself. You will see how
> > > un-worthwhile the modifications are for the existing use cases.
> >
> >
> > Again, I'm not contending for Valgrind internal changes. I would
> > contend, however, that being able to reliably detect when a thread
> > starts/stops within instrumented code is valuable.
> >
> > I've seen the track_{start,stop}_client_code callbacks suggested, but
> > I've also seen that VG_(get_running_tid)() is supposed to be more
> > reliable. e.g.
> >
> http://www.mail-archive.com/val...@li.../msg03441.html
> >
> >
> > Thank you again,
> > Mike
> >
> ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________ Valgrind-users mailing
> list Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>
|