On Fri, Feb 22, 2019 at 06:11:44PM -0700, Kevin Buettner wrote:
> For debugging purposes, I need to be able to find the master thread
> in the thread pool.
>
> Without this patch, I see over 20 failures in the tests that I've
> written for GDB.
>
> I've also tested this in the gcc tree - no regressions.
>
> libgomp/ChangeLog:
>
> * team.c (gomp_team_start): Initialize pool->threads[0].
If it is really needed, then it might be much better to just do it
unconditionally, i.e.
pool->threads[0] = thr;
after the realloc, I don't see what doing it conditionally buys us,
gomp_realloc is already slow enough and even from cache-line ownership POV
at least when it is actually reallocated it shouldn't make a difference.
That said, I'd like to better understand what do you need it for.
When do you need to find the master thread, do you have some special case
when number of threads in the team is 1? Because in that case pool->threads
will be often NULL. I admit handling that case is quite trivial, but
I'm still asking if it is handled.
What do you do for the case of nested parallelism? There are no thread
pools ATM, so how do you find the master thread in that case?
In theory, albeit more costly, one could find the thread that owns the
thread pool just by iterating over all threads and checking which thread
has gomp_tls_data.thread_pool equal to the pool in which you'd query
pool->threads, though I admit it is likely unacceptable e.g. for
ompd_get_thread_in_parallel we'll need to implement at some point too
(finding a master thread is passing 0 as the thread num in that case).
Jakub
