This is the mail archive of the
mailing list for the pthreas-win32 project.
Re: Mutex implementation questions
- To: Tristan Savatier <tristan at mpegtv dot com>
- Subject: Re: Mutex implementation questions
- From: Ross Johnson <rpj at ise dot canberra dot edu dot au>
- Date: Mon, 09 Oct 2000 15:58:22 +1100
- CC: "Bossom, John" <John dot Bossom at Cognos dot COM>, "'pthreads-win32 at sources dot redhat dot com'" <pthreads-win32 at sources dot redhat dot com>
- Organization: University of Canberra, Information Sciences and Engineering
- References: <430F887D415DD1118C2700805F31ECF1037F1394@SOTA0005> <39DD417E.FD05A413@mpegtv.com>
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 initialization/cleanup)
> 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 |