Re: Using posix calls in rotor code

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