The GC suspends only managed threads, and as you point out, will "trap" them asynchronously. See ThreadStore::TrapReturningThreads for the logic. This is called from GCHeap::SuspendEE, so you've probably taken a look at it.
Managed code and native code are sharing thread stacks as well as shared resources such as locks, and so suspending unmanaged threads directly would sometimes lead to deadlock. (There is no way for the EE to track what is going on in "foreign" C++ code...) What happens is that the EE watches for threads that are returning from forays into unmanaged code, and nabs them when they come back. The Unix PAL has a similar mechanism. Since pthreads has no standard way to suspend/resume (or to have nested suspensions via a suspend count, as win32 does), platform-specific calls are used (pthread_suspend_np on freebsd and thread_suspend on mach). These are invoked only after bookkeeping is done, necessitating an async approach. Because the PAL uses critsecs to protect internal structures, this code is very susceptible to deadlock -- the PAL uses a conservative approach that spins threads up and down in order to avoid deadlock. The consequence is that the code is *far* from synchronous. :) Where are you seeing synchronous suspension? Could you be more specific about what you're seeing that you'd like to understand? -- David Stutz -----Original Message----- From: Archana Ravindar [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 2:53 AM To: [EMAIL PROTECTED] Subject: [DOTNET-ROTOR] suspension of threads in rotor Hi, Can someone please explain about the modes of suspension in rotor. i believe there are two of them- synchronous and asynchronous 1. in what situations are these two schemes used in the CLR? 2. Does the GC in rotor use both of them to stop the world when it calls suspendEE? thanks and regards, archana
