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
