This is the mail archive of the
pthreads-win32@sources.redhat.com
mailing list for the pthreas-win32 project.
Mutex implementation questions
- To: "'pthreads-win32 at sources dot redhat dot com'" <pthreads-win32 at sources dot redhat dot com>
- Subject: Mutex implementation questions
- From: Tristan Savatier <tristan at mpegtv dot com>
- Date: Mon, 02 Oct 2000 15:10:22 -0700
- Organization: MpegTV - http://www.mpegtv.com - +1 415 864 6466
- References: <430F887D415DD1118C2700805F31ECF1037F1388@SOTA0005>
I noticed that if _pthread_try_enter_critical_section has been set
to a non-NULL value by DllMain, Mutexes are implemented using
critical sections (InitializeCriticalSection) instead of
CreateMutex, regardless of the value of the implemetation-specific
forcecs
mutex attribute.
According to "Win32 programming", critical sections are light weight
compared to mutexes, they are not managed by the kernel, and they
are much faster than mutexes. So why no use critical sections
all the time to implement pthread mutexes ?
Are there cases where critical sections are not available or
wouldn't work well ?
The DllMain seems to do some tests to check if InitializeCriticalSection
exists and works. What are the cases where critical sections
would not be available ?
Also, I have a suggestion:
It might be a good idea to add a compile flag to
allow the use of pthread-win32 with static linking
(i.e. to make just a pthread.lib, no dll).
In this case, a compilation flag should be added to exclude the DllMain
routine. Also, the code that sets _pthread_try_enter_critical_section
should be moved from DllMain to _pthread_processInitialize. The
_pthread_processInitialize should be made global and it should
be called by the application to initialize pthread.
We had to change the pthread code to do all that in our
WinCE application.
-t