Re: Mutex implementation questions

[Ross Johnson <rpj at ise dot canberra dot edu dot au>]

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.

Ross

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
> thread
> terminate by calling pthread_exit(void *), and do not "fall through the
> bottom"
> 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:
> 
>   _pthread_callUserDestroyRoutines((pthread_t)
> pthread_getspecific(_pthread_selfThreadKey));
> 
> by:
>   _pthread_threadDestroy((pthread_t)
> pthread_getspecific(_pthread_selfThreadKey));
> 
> which calls _pthread_callUserDestroyRoutines and then does the necessary
> cleanup
> of the thread TSD.
> 
> That takes are of the thread cleanup.  Regarding the process cleanup, I
> suppose
> 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
> support
> 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
> in
> 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...
> 
> -t
> 
> > I hope this clears up some of your questions.
> >
> > Cheers,
> >
> > John.
> >
> > -----Original Message-----
> > From: Tristan Savatier [mailto:tristan@mpegtv.com]
> > Sent: Monday, October 02, 2000 6:10 PM
> > To: 'pthreads-win32@sources.redhat.com'
> > 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: rpj@ise.canberra.edu.au
| 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                |
+--------------------------+