You shouldn't have problems if you add additional thread synchronization code. The suspend/resume code is reasonably robust - it suspends each thread, and if the thread is not executing managed code, it immediately resumes it and lets the thread run until it re-enters managed code. As long as you don't introduce new locks that need to be acquired by the actual suspend/resume code in the EE, you shouldn't see deadlocks.
Be very careful adding new locks into the PAL - if you do, you'll need to update the critsec_count in order to avoid PAL-internal deadlocks. Barry This posting is provided "AS IS" with no warranties, and confers no rights. -----Original Message----- From: Discussion of the Rotor Shared Source CLI implementation [mailto:[EMAIL PROTECTED] On Behalf Of Archana Sent: Friday, June 20, 2003 4:45 AM To: [EMAIL PROTECTED] Subject: [DOTNET-ROTOR] Using posix calls in rotor code Hi, Can we use Posix calls for thread synchronization in rotor code? because almost all calls used are the ones that are defined in /pal/unix directory. and crucial functions such as suspendEE, restartEE assume that all the threads are objects of 'class Thread'. to be more specific, if we introduce pthread mutexes/semaphores in the code, what precautions should one take to ensure that the gc thread is successful in suspending all the threads? Thanks & regards archana
