From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Johnson To: Tristan Savatier Cc: "Bossom, John" , "'pthreads-win32@sources.redhat.com'" Subject: Re: Mutex implementation questions Date: Sun, 08 Oct 2000 21:58:00 -0000 Message-id: <39E1506E.56399693@ise.canberra.edu.au> References: <430F887D415DD1118C2700805F31ECF1037F1394@SOTA0005> <39DD417E.FD05A413@mpegtv.com> X-SW-Source: 2000/msg00123.html 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 | +--------------------------+