You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[threads] Use refcounts for coordinating finalization and detaching
Reverts a29ad08 (mono#9914)
The basic problem we want to solve is the following:
1. All access to InternalThread:state must be protected by the
InternalThread:synch_cs mutex
2. We must destroy the mutex when we are done with the thread.
3. We don't know which happens later - detaching the machine thread or
finalizing its InternalThread managed object.
The solution is to replace InternalThread:synch_cs by InternalThread:longlived
which is a refcounted struct that holds the synch_cs. The refcount starts out
at 2 when the thread is attached to the runtime and when we create the managed
InternalThread object that represents it.
Both detaching and finalizing the managed object will decrement the refounct,
and whichever one happens last will be responsible for destroying the mutex.
This addresses mono#11956 which was a race
condition due to the previous attempt to fix this lifetime problem. The
previous attempt incorrectly used CAS in mono_thread_detach_internal while
continuing to use locking of synch_cs elsewhere. In particular
mono_thread_suspend_all_other_threads could race with
mono_thread_detach_internal: it expects to take the thread lock and test
thread->state and use the thread->suspended event, while detaching deletes
thread->suspended without taking a lock.
As a result we had a concurrency bug: in suspend_all_other_threads it's
possible to see both the old (non-Stopped) value of thread->state and the
new (NULL) value of thread->suspended. Which leads to crashes.
---
Background - why we don't know if detaching or finalization happens first.
1. InternalThread normally outlives the machine thread. This can happen because
when one thread starts another it can hold a reference to the fresh thread's
Thread object which holds a reference to the InternalThread. So after the
machine thread is done, the older thread can query the state of the younger
Thread object. This is the normal situation.
2. During shutdown we can have the opposite situation: the InternalThread
objects are finalized first (this happens during root domain finalization), but
the machine threads are still running, and they may still return to
start_wrapper_internal and call detach_internal. So in this case we have an
InternalThread whose finalizer ran first and detach will run second.
Copy file name to clipboardExpand all lines: mono/metadata/object-internals.h
+5-2Lines changed: 5 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -510,7 +510,7 @@ struct _MonoInternalThread {
510
510
gpointerunused3;
511
511
gunichar2*name;
512
512
guint32name_len;
513
-
guint32state;
513
+
guint32state;/* must be accessed while longlived->synch_cs is locked */
514
514
MonoException*abort_exc;
515
515
intabort_state_handle;
516
516
guint64tid; /* This is accessed as a gsize in the code (so it can hold a 64bit pointer on systems that need it), but needs to reserve 64 bits of space on all machines as it corresponds to a field in managed code */
@@ -524,7 +524,10 @@ struct _MonoInternalThread {
524
524
gpointerappdomain_refs;
525
525
/* This is modified using atomic ops, so keep it a gint32 */
526
526
gint32__interruption_requested;
527
-
MonoCoopMutex*synch_cs;
527
+
/* data that must live as long as this managed object is not finalized
528
+
* or as long as the underlying thread is attached, whichever is
0 commit comments