In PR29286 I ran into a few race condition that are now hard to reproduce, but not fixed AFAICT. See f.i. the patch at PR 29286 comment 6. Which made me wonder which other race conditions are lurking. I wonder if there's anything I can do to flush these out. From what I understand, the race conditions are due to executing this: ... void cooked_index::finalize () { m_future = gdb::thread_pool::g_thread_pool->post_task ([this] () { do_finalize (); }); } ... and not waiting for it, so perhaps adding a sleep () here could help?
I tried this: ... diff --git a/gdb/dwarf2/cooked-index.c b/gdb/dwarf2/cooked-index.c index adb0046609e..d8f5cfdcdbe 100644 --- a/gdb/dwarf2/cooked-index.c +++ b/gdb/dwarf2/cooked-index.c @@ -119,6 +119,7 @@ cooked_index::finalize () { m_future = gdb::thread_pool::g_thread_pool->post_task ([this] () { + usleep (1 * 1000 * 1000); do_finalize (); }); } ... but no results.
Another idea I had was to make sure that this in parallel_for: ... /* Process all the remaining elements in the main thread. */ return results.finish ([=] () { return callback (first, last); }); ... is not run on the main thread, but only in the thread pool, to maximize the skew between main thread and parallel for, but given that the parallel for waits for the elements to finish, I don't expects any results from this currently. But if we start to use thread_local memory, this could be something useful to try.
(In reply to Tom de Vries from comment #2) > Another idea I had was to make sure that this in parallel_for: > ... > /* Process all the remaining elements in the main thread. */ > return results.finish ([=] () > { > return callback (first, last); > }); > ... > is not run on the main thread, but only in the thread pool, to maximize the > skew between main thread and parallel for, but given that the parallel for > waits for the elements to finish, I don't expects any results from this > currently. > > But if we start to use thread_local memory, this could be something useful > to try. https://sourceware.org/pipermail/gdb-patches/2022-July/190830.html
(In reply to Tom de Vries from comment #3) > (In reply to Tom de Vries from comment #2) > > Another idea I had was to make sure that this in parallel_for: > > ... > > /* Process all the remaining elements in the main thread. */ > > return results.finish ([=] () > > { > > return callback (first, last); > > }); > > ... > > is not run on the main thread, but only in the thread pool, to maximize the > > skew between main thread and parallel for, but given that the parallel for > > waits for the elements to finish, I don't expects any results from this > > currently. > > > > But if we start to use thread_local memory, this could be something useful > > to try. > > https://sourceware.org/pipermail/gdb-patches/2022-July/190830.html This was not deemed acceptable in review. I've done all I could think of, so I'm marking this task done, even though there are no actual resulting commits.