This is the mail archive of the
mailing list for the pthreas-win32 project.
RE: Mutex implementation questions
- To: 'Ross Johnson' <rpj at ise dot canberra dot edu dot au>, "'pthreads-win32 at sources dot redhat dot com'" <pthreads-win32 at sources dot redhat dot com>
- Subject: RE: Mutex implementation questions
- From: "Bossom, John" <John dot Bossom at Cognos dot COM>
- Date: Wed, 11 Oct 2000 11:37:06 -0400
The ptw32_threadStart() is only used (correct me if I am wrong)
if someone explicitly calls pthread_create. Hence, anyone using
other simulated features of the win32-pthread library within
a "foreign" thread body will encounter cleanup/leak problems.
For example, using TSD with a destructor... the destructor will
not be called if a value is stored from within a foreign thread
body (such as the main process). You will then be forced to only
use any of the pthread types from within a thread explicitly
created with pthread_create. Perhaps this is a valid restriction
for those wanting to use a static link library as opposed to
The reason for the introduction of a DllMain was to ensure that
you can use any of the pthread types exactly like on UNIX. I
understand the concern over lack of DLL versioning from Microsoft.
However, it could be implemented ourselves through the use of
a thin library that dynamically loads the Dll by name (including
From: Ross Johnson [mailto:email@example.com]
Sent: Monday, October 09, 2000 12:58 AM
To: Tristan Savatier
Cc: Bossom, John; 'firstname.lastname@example.org'
Subject: Re: Mutex implementation questions
With regard to possibly eliminating dllMain for applications
linking pthread*.lib statically - rather than require all threads
to explicitly call pthread_exit(), is there any reason why the
DLL_THREAD_DETACH code in dllMain can't be moved to
private.c:ptw32_threadStart(), which is the wrapper for the
applications threads? It looks doable to me. That leaves
just the DLL_PROCESS_DETACH code which could be called
explicitly as suggested.
Tristan Savatier wrote:
> Bossom, John wrote:
> > 4) By eliminating the DllMain, whose purpose was to perform
> > behind the scenes cleanup of the "self" structure as well as calling
> > all the destructors for thread-specific data keys, what alternate
> > approach did you take for doing this thread-based cleanup?
> > (i.e. I leveraged the fact that DllMain is called each time a thread
> > is started/finished to perform thread based
> You are right. One thing that can be done is to make sure that all
> terminate by calling pthread_exit(void *), and do not "fall through the
> of the threan entry-point routine (which is allowed by the standard).
> That's what we do, and to make it work, we modified pthread_exit
> by replacing:
> which calls _pthread_callUserDestroyRoutines and then does the necessary
> of the thread TSD.
> That takes are of the thread cleanup. Regarding the process cleanup, I
> that _pthread_processTerminate() should be called explicitely if the dll
> is not used.
> Now, maybe you wonder why we prefer to link statically rather that
> to use the DLL (pthread.dll). The reason is that Windows does not
> dll versionning, i.e. if several applications rely on pthread.dll, but
> on various versions of it, things break. There would be a solution
> which is
> to place the dll in the same directory as the application, rather than
> the \Windows directory, but this also breaks due to the stupid rule used
> by Windows to look for dll's: first it looks in \Windows, then in the
> other places... which means that if another application places an
> incompatible pthread.dll in \windows, it will break you application
> (we had the experience with applications using xaudio.dll).
> And pthread is so small that the gain of having it shared (compared
> to the trouble) is small.
> That's why we think that using pthread.dll is a BAD idea, and that
> static linking with pthread.lib is a safer solution...
> > I hope this clears up some of your questions.
> > Cheers,
> > John.
> > -----Original Message-----
> > From: Tristan Savatier [mailto:email@example.com]
> > Sent: Monday, October 02, 2000 6:10 PM
> > To: 'firstname.lastname@example.org'
> > Subject: Mutex implementation questions
> > 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
> Regards, -- Tristan Savatier (President, MpegTV LLC)
> MpegTV: http://www.mpegtv.com - Tel: (415) 864 6466
> PocketTV: http://www.pockettv.com - Fax: (415) 704 3224
| Ross Johnson | | E-Mail: email@example.com
| Info Sciences and Eng|___|
| University of Canberra | FAX: +61 6 2015227
| PO Box 1 |
| Belconnen ACT 2616 | WWW: http://willow.canberra.edu.au/~rpj/
| AUSTRALIA |