Fix deadlock

[cshung]

What's wrong?

When I was prototyping the NoGC support for regions, I notice that my code ran into a deadlock when running under server GC. When I observe the threads in detail, it appears the threads are blocking on different joins.

Why does that happen?
The majority of the code requires that the server GC threads all start together, follow the same path (with respect to joins), and therefore they should all be before the same join and all march towards the next join.

The issue with this bug is that in a special case, a particular GC thread started earlier than the others and lead towards a different path.

In particular, in a normal case, we expect all threads to be waiting at the beginning of the gc_thread_function. Except for the heap 0 thread, which blocks on the ee_suspend_event, all other threads should be blocking on the gc_start_event.

However, in the case of minimal_gc_p == TRUE, the work to reset the gc_start_event is skipped. Therefore when one thread is done with the work, it proceeds to run the next iteration right away without being blocked in the gc_start_event, and that is bad because the heap 0 thread will be waiting regardless, so all threads are not running in locked steps.

The fix?
I make sure the last thread entered the initial join reset the gc_start_event before letting all threads return from garbage_collect. This will ensure all threads get blocked on the same waiting condition, just like it was for the minimal_gc_p == FALSE case after generation_to_condemn.

Note that this fix is independent of USE_REGIONS, meaning it might happen in previous releases. We might want to consider backport this fix to earlier LTS.

[ghost]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

What's wrong?

When I was prototyping the NoGC support for regions, I notice that my code ran into a deadlock when running under server GC. When I observe the threads in detail, it appears the threads are blocking on different joins.

Why does that happen?
The majority of the code requires that the server GC threads all start together, follow the same path (with respect to joins), and therefore they should all be before the same join and all march towards the next join.

The issue with this bug is that in a special case, a particular GC thread started earlier than the others and lead towards a different path.

In particular, in a normal case, we expect all threads to be waiting at the beginning of the gc_thread_function. Except for the heap 0 thread, which blocks on the ee_suspend_event, all other threads should be blocking on the gc_start_event.

However, in the case of minimal_gc_p == TRUE, the work to reset the gc_start_event is skipped. Therefore when one thread is done with the work, it proceeds to run the next iteration right away without being blocked in the gc_start_event, and that is bad because the heap 0 thread will be waiting regardless, so all threads are not running in locked steps.

The fix?
I make sure the last thread entered the initial join reset the gc_start_event before letting all threads return from garbage_collect. This will ensure all threads get blocked on the same waiting condition, just like it was for the minimal_gc_p == FALSE case after generation_to_condemn.

Note that this fix is independent of USE_REGIONS, meaning it might happen in previous releases. We might want to consider backport this fix to earlier LTS.

Author:	cshung
Assignees:	-
Labels:	area-GC-coreclr
Milestone:	-

[Maoni0]

LGTM!

[PeterSolMS]

Ok, makes sense.