RE: Memory leak in pthread_setcanceltype()?

RE: Memory leak in pthread_setcanceltype()?

[Bossom, John]

I hope the following quotes help... (a bit!)

From "Programming with POSIX Threads", by David R. Butenhof, page 51:

    "When you no longer need a mutex that you dynamically initialized
     by calling pthread_mutex_init, you should destroy the mutex by calling
     pthread_mutex_destroy. You do not need to destroy a mutex that was
     statically initialized using the PTHREAD_MUTEX_INITIALIZER macro."

From "Programming with THREADS", by Steve Kleiman, Devang Shah,
Bart Smaalders", page 27:
    "Mutexes are destroyed by calling:
     int
     pthread_mutex_destroy(pthread_mutex_t *mp);

     The mutex that is destroyed must have been initialized either
statically
     or by using pthread_mutex_init()."

From "THREADS Primer, A Guide to Multithreaded Programing", by Bil Lewis
and Daniel J. Berg, page 251:

    "... In cases where default mutex attributes are appropriate, the macro
     PTHREAD_MUTEX_INITIALIZER can be used to initialize mutexes that are
     statically allocated. The effect is equivalent to dynamic
initialization
     by a call to pthread_mutex_init() with parameter 'attr' specified as
     NULL, except that no error checks are performed."
    (This is exactly what the man page on SOLARIS states as well)


-----Original Message-----
From: reentrant [ mailto:reentrant@yahoo.com ]
Sent: Thursday, September 28, 2000 11:56 AM
To: rpj@ise.canberra.edu.au; Alastair Hume
Cc: 'pthreads-win32@sources.redhat.com'
Subject: Re: Memory leak in pthread_setcanceltype()?



I don't know for a fact, but I'd be leary about calling
pthread_mutex_destroy()
on a mutex not initialized with pthread_mutex_init() (i.e. initialied with
PTHREAD_MUTEX_INITIALIZER).  It feels like free()ing a pointer to a char
array
allocated on the stack to me.  I certainly wouldn't depend on calling
pthread_mutex_destroy() on a mutex not initialized via pthread_mutex_init()
to
be portable.

From the sound of it, to be safe I'd personally recommend avoiding the
PTHREAD_MUTEX_INITIALIZER and use pthread_mutex_init() to initialize and
pthread_mutex_destroy() to destroy.

I've used a mutex class since 11/99 that does exactly that without any flags
from purify or boundschecker (but using a 10/99 pthreads snapshot...).

Dave

--- Ross Johnson <rpj@ise.canberra.edu.au> wrote:
> Hi,
> 
> I could be wrong since C++ is not a strongpoint for me, but your Mutex
> class constructs the mutex as a PTHREAD_MUTEX_INITIALIZER but you
> don't call pthread_mutex_destroy() in the destructor. The way that
> pthreads-win32 implements static initialised mutexes is to calloc
> the mutex struct the first time pthread_mutex_lock() is called on
> that mutex. Perhaps other Pthreads implementations don't require
> this but I think destroying a static mutex is legal and portable.
> 
> Ross
> 
> Alastair Hume wrote:
> > 
> > Hello,
> > 
> > I'm using Pthreads win32 (snapshot 2000-09-08) with Visual C++ (6.0) and
> > Windows2000 and I am getting lots of memory leaks flagged by Purify and
> > BoundsChecker.  I'm using the precompiled DLL obtained from
> > < ftp://sources.redhat.com/pub/pthreads-win32/dll-latest >.
> > 
> > These leaks occur in (at least) calls to phread_mutex_lock(),
> > pthread_cond_wait() and pthread_cond_timedwait() and at typically about
28
> > bytes per leak.
> > 
> > Purify reports these memory leaks as:
> > 
> > MLK: Memory leak of 28 bytes from 1 block allocated in
> pthread_setcanceltype
> >         Distribution of leaked blocks
> >                 28 bytes from 1 block of 28 bytes (0x02105db0)
> >         Allocation location
> >             calloc         [msvcrt.DLL]
> >             pthread_setcanceltype [pthreadVSE.dll]
> >             pthread_setcanceltype [pthreadVSE.dll]
> >             pthread_setcanceltype [pthreadVSE.dll]
> >             SDSUtility::Mutex::lock(void) [SDSUtility_Mutex.cpp:61]
> >                 {
> >                 #ifdef _MT
> > 
> >              =>     pthread_mutex_lock( &m_objectMutex );
> > 
> >                 #endif
> >                 }
> > and:
> > 
> > MLK: Memory leak of 20 bytes from 1 block allocated in
> pthread_setcanceltype
> >         Distribution of leaked blocks
> >                 20 bytes from 1 block of 20 bytes (0x02106200)
> >         Allocation location
> >             calloc         [msvcrt.DLL]
> >             pthread_setcanceltype [pthreadVSE.dll]
> >             pthread_setcanceltype [pthreadVSE.dll]
> >             pthread_setcanceltype [pthreadVSE.dll]
> >             pthread_setcanceltype [pthreadVSE.dll]
> >             SDSDataStore::Query::waitForTrigger(void)
> > [SDSDataStore_Query.cpp:136]
> >                     if( !m_triggered && !m_terminated )
> >                     {
> >              =>         pthread_cond_wait( &m_triggered_cond, &m_mutex
);
> >                     }
> > 
> > BoundsChecker reports the first leak as:
> > 
> > Bounds checker reports this as:
> > 
> > Memory leak: 28 bytes allocated by calloc in
> PTHREADVSE.DLL!00002AC1,HANDLE:
> > 0x00303A10
> > PTHREADVSE.DLL!00002AC1()       (unknown)       (unknown)
> > PTHREADVSE.DLL!00002AC1()       (unknown)       (unknown)
> > PTHREADVSE.DLL!00002AC1()       (unknown)       (unknown)
> > SDSUtility::Mutex::lock()
> > C:\Scorpion\source\SDSUtility\SDSUtility_Mutex.cpp      61
> > 
> > Does anybody know if this is a known problem?  Can anybody point me to
> > something I could be doing wrong to cause this problem.  I have tried
using
> > both the VSE and VCE versions.  I also hacked up a simple program which
> > locks and unlocks a pthread mutex and purify does not find any leaks in
it
> > so it is likely to be something within my more complicated program but
I'm
> > not sure what I can do to release memory allocated by a call to
> > pthread_mutex_lock() - have I missed something?
> > 
> > Below is my implementation of my Mutex class whose lock() methods
creates
> > the first leak listed above, just incase anybody can see anything
obviously
> > stupid in this.
> > 
> > Any help in pointing me in the right direction would be very much
> > appreciated.
> > 
> > Thanks,
> > 
> > Ally Hume
> > Concept Systems Limited
> > 
> > Mutex.h
> > 
> > #include <pthread.h>
> > 
> > class Mutex
> > {
> > public:
> > 
> >     /// Constructor
> >     Mutex();
> > 
> >     /// Destructor
> >     ~Mutex();
> > 
> >     /**
> >     *** Locks the mutex.  Blocks until the lock is obtained
> >     **/
> >     void lock();
> > 
> >     /**
> >     *** Unlocks the mutex
> >     **/
> >     void unlock();
> > 
> > private:
> > 
> >     // Synchronization object
> > 
> > #ifdef _MT
> > 
> >     pthread_mutex_t    m_objectMutex;                       ///< global
> > object mutex
> > 
> > #endif
> > 
> > };
> > 
> > Mutex.cpp
> > 
> > /// Constructor
> > Mutex::Mutex()
> > #ifdef _MT
> >     : m_objectMutex( PTHREAD_MUTEX_INITIALIZER )
> > #endif
> > {
> > }
> > 
> > /// Destructor
> > Mutex::~Mutex()
> > {
> > }
> > 
> > /**
> > *** Locks the mutex.  Blocks until the lock is obtained
> > **/
> > void
> > Mutex::lock()
> > {
> > #ifdef _MT
> > 
> >     pthread_mutex_lock( &m_objectMutex );
> > 
> > #endif
> > }
> > 
> > /**
> > *** Unlocks the mutex
> > **/
> > void
> > Mutex::unlock()
> > {
> > #ifdef _MT
> > 
> >     pthread_mutex_unlock( &m_objectMutex );
> > 
> > #endif
> > }


__________________________________________________
Do You Yahoo!?
Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
http://photos.yahoo.com/

Mutex implementation questions

[Tristan Savatier]

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

Re: Mutex implementation questions

[Ross Johnson]

Tristan Savatier wrote:
> 
> 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 ?
> 

Win9x doesn't support TryEnterCriticalSection, hence the fallback
to Win32 mutexes on those platforms. On Win98 that function
appears to be a stub that does nothing hence the need to test it
by actually initialising a CS and attempting to acquire it.

The forcecs hook is there if your application never needs to use
pthread_mutex_trylock() and you want the performance advantage.
It could perhaps be better implemented as a non-portable per
mutex attribute (or either option could be provided).

> 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.

This sounds like a good idea for static linked libraries.

Cheers.
Ross

-- 
+----------------------+---+
| 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                |
+--------------------------+

RE: Mutex implementation questions

[Bossom, John]

Hi Ross!

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
a DLL.

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
version codes).

Cheers,

John.

-----Original Message-----
From: Ross Johnson [ mailto:rpj@ise.canberra.edu.au ]
Sent: Monday, October 09, 2000 12:58 AM
To: Tristan Savatier
Cc: Bossom, John; 'pthreads-win32@sources.redhat.com'
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.

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                |
+--------------------------+

Re: Mutex implementation questions

[Ross Johnson]

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                |
+--------------------------+

Re: Mutex implementation questions

[Tristan Savatier]

Bossom, John wrote:
> 
> You are correct... critical sections are almost 100 times faster than
> actual kernel based mutexes... however...

That's right. Regarding pthread-win32 running on WinCE (PocketPC),
I was able to get a very significant gain of performances on
the overall application (5% to 15%) now that our mutexes use
critical sections (TryEnterCriticalSection works on WinCE 3.0 / Pocket
PC).

Note that we had to make a minor change to fix mutexes on WinCE:

#ifdef UNDER_CE
	  _pthread_h_kernel32 = LoadLibrary(TEXT("COREDLL.DLL"));
#else
	  _pthread_h_kernel32 = LoadLibrary(TEXT("KERNEL32.DLL"));
#endif

Because on WinCE, the symbol TryEnterCriticalSection is part of
COREDLL.DLL (there is no KERNEL32.DLL).

> 1) Mutexes (i.e. kernel based) are useful in that you can support a
>    lock-with-timeout... a feature that is being pondered as an upgrade
>    to pthreads.

true.

> 2) Mutexes can use WaitForMultipleObjects (sp?) which allows you to simulate
>    a cancel by waiting on a cancel event as well as the mutex.

true, but in some cases cancellation is not a problem, and performances
is
critical.

> 3) TryEnterCriticalSection is not supported on Win95/98 (originally it was
>    completely left out... then they added a stub that simply returns
>    "function not supported", thus there is no way to implement
>    pthread_mutex_trylock; hence if you need "trylock" you need to use a
>    real mutex.

true. but it works on NT/2000 (and WinCE 3.0)

> 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

RE: Mutex implementation questions

[Bossom, John]

You are correct... critical sections are almost 100 times faster than
actual kernel based mutexes... however...

1) Mutexes (i.e. kernel based) are useful in that you can support a
   lock-with-timeout... a feature that is being pondered as an upgrade
   to pthreads.
2) Mutexes can use WaitForMultipleObjects (sp?) which allows you to simulate
   a cancel by waiting on a cancel event as well as the mutex.
3) TryEnterCriticalSection is not supported on Win95/98 (originally it was
   completely left out... then they added a stub that simply returns
   "function not supported", thus there is no way to implement
   pthread_mutex_trylock; hence if you need "trylock" you need to use a
   real mutex.
3) 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)

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

Re: Mutex implementation questions

[Ross Johnson]

Tristan Savatier wrote:
> 
> > Scott McCaskill wrote:
> >
> >
> > Yes, I'm pretty sure critical sections can't be shared between
> > processes (but mutexes can).  So this may be the reason.
> 
> Yes, but does the pthread API  permit the creation of pthread mutexes
> that
> are shared between processes ?

Pthreads-win32 doesn't have them yet, but it does have the
functions (pthread_*_*pshared) defined. Those and some others emit
an error if you try to use process shared objects.

_POSIX_THREAD_PROCESS_SHARED is not defined in pthreads-win32.

Ross

-- 
+----------------------+---+
| 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                |
+--------------------------+

Re: Mutex implementation questions

[Tristan Savatier]

> Scott McCaskill wrote:
> 
> 
> Yes, I'm pretty sure critical sections can't be shared between
> processes (but mutexes can).  So this may be the reason.

Yes, but does the pthread API  permit the creation of pthread mutexes
that
are shared between processes ?

If not, then what would be the advantage of using  CreateMutex
rather than InitializeCriticalSection ?

-t

RE: Mutex implementation questions

[Scott McCaskill]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

Title: RE: Mutex implementation questions







> -----Original Message-----
> From: Tristan Savatier [ mailto:tristan@mpegtv.com ]
> Sent: Monday, October 02, 2000 5: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 ?
> 


Yes, I'm pretty sure critical sections can't be shared between processes (but mutexes can).  So this may be the reason.