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 <
philippe.waroqui...@skynet.be> 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/valgrind-users@lists.sourceforge.net/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 Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>
------------------------------------------------------------------------------
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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
