critical section

critical section

[Ye Liu]

Greets,

When I impelement the critical section using mutex, I have the following
code:

/*    TIBMutex.h    */
#ifndef _TIBMutex_H_
#define _TIBMutex_H_
class TIBMutex
{
public:
    TIBMutex();
     ~TIBMutex();
     void acquire();
     void acquire_yield();
     void release();
     int tryacquire();

private:
    pthread_mutex_t m_Mutex;
    pthread_mutexattr_t m_MutexAttr;
    void init_MutexAttr();
    int m_Count;
};

/*    TIBMutex.cpp    */
TIBMutex::TIBMutex()
{
 m_Count = 0;
 if  (pthread_mutex_init(&m_Mutex, &m_MutexAttr))
    /* error handling...*/
}

inline void TIBMutex::acquire()
{
 while (m_Count);

 if (pthread_mutex_lock(&m_Mutex))
 {
     /* error handling...*/
 }
 ++m_Count;
 return;
}

inline void TIBMutex::release()
{
 if (pthread_mutex_unlock(&m_Mutex))
 {
    /* error handling...*/
 }
 --m_Count;
}

My questions are:

1. Do I need use a condition variable here because I use m_Count as 0/1
signal?

2. In the acquire(), when m_Count is not 0, the waiting thread should
"spin" there as the above or yield like the following acquire_yield()

inline void TIBMutex::acquire_yield()
{
 while (m_Count)
  shed_yield();
 if (pthread_mutex_lock(&m_Mutex))
 {
    /* error handling...*/
 }
 ++m_Count;
 return;
}


--
Ye Liu
Tel(O) 650-846-5228

Re: critical section

[Scott McCaskill]

It looks like you're trying to make a non-recursive mutex (can only be
locked once by any thread, including the mutex owner).  pthread_mutex can
already do this; is there some reason you're not using it this way directly?
See pthread_mutexattr_settype().

----- Original Message -----
From: "Ye Liu" <yliu@tibco.com>
To: "win32-pthread" <pthreads-win32@sourceware.cygnus.com>
Sent: Tuesday, July 31, 2001 4:27 PM
Subject: critical section


> Greets,
>
> When I impelement the critical section using mutex, I have the following
> code:
>
> /*    TIBMutex.h    */
> #ifndef _TIBMutex_H_
> #define _TIBMutex_H_
> class TIBMutex
> {
> public:
>     TIBMutex();
>      ~TIBMutex();
>      void acquire();
>      void acquire_yield();
>      void release();
>      int tryacquire();
>
> private:
>     pthread_mutex_t m_Mutex;
>     pthread_mutexattr_t m_MutexAttr;
>     void init_MutexAttr();
>     int m_Count;
> };
>
> /*    TIBMutex.cpp    */
> TIBMutex::TIBMutex()
> {
>  m_Count = 0;
>  if  (pthread_mutex_init(&m_Mutex, &m_MutexAttr))
>     /* error handling...*/
> }
>
> inline void TIBMutex::acquire()
> {
>  while (m_Count);
>
>  if (pthread_mutex_lock(&m_Mutex))
>  {
>      /* error handling...*/
>  }
>  ++m_Count;
>  return;
> }
>
> inline void TIBMutex::release()
> {
>  if (pthread_mutex_unlock(&m_Mutex))
>  {
>     /* error handling...*/
>  }
>  --m_Count;
> }
>
> My questions are:
>
> 1. Do I need use a condition variable here because I use m_Count as 0/1
> signal?
>
> 2. In the acquire(), when m_Count is not 0, the waiting thread should
> "spin" there as the above or yield like the following acquire_yield()
>
> inline void TIBMutex::acquire_yield()
> {
>  while (m_Count)
>   shed_yield();
>  if (pthread_mutex_lock(&m_Mutex))
>  {
>     /* error handling...*/
>  }
>  ++m_Count;
>  return;
> }
>
>
> --
> Ye Liu
> Tel(O) 650-846-5228
>
>
>

Re: critical section

[Ye Liu]

In the book of "Programming with POSIX Threads",  the author metioned

"You cannot lock a mutex when the calling thread already has that mutex locked."

My previous understanding is "a mutex cannot be locked twice", which obviously
is wrong.

If I use a non-recursive mutex, when a thread try to lock the mutex which is
already locked by another one, what happens to the calling thread? Spin or
yield?

--ye

Scott McCaskill wrote:

> It looks like you're trying to make a non-recursive mutex (can only be
> locked once by any thread, including the mutex owner).  pthread_mutex can
> already do this; is there some reason you're not using it this way directly?
> See pthread_mutexattr_settype().
>
> ----- Original Message -----
> From: "Ye Liu" <yliu@tibco.com>
> To: "win32-pthread" <pthreads-win32@sourceware.cygnus.com>
> Sent: Tuesday, July 31, 2001 4:27 PM
> Subject: critical section
>
> > Greets,
> >
> > When I impelement the critical section using mutex, I have the following
> > code:
> >
> > /*    TIBMutex.h    */
> > #ifndef _TIBMutex_H_
> > #define _TIBMutex_H_
> > class TIBMutex
> > {
> > public:
> >     TIBMutex();
> >      ~TIBMutex();
> >      void acquire();
> >      void acquire_yield();
> >      void release();
> >      int tryacquire();
> >
> > private:
> >     pthread_mutex_t m_Mutex;
> >     pthread_mutexattr_t m_MutexAttr;
> >     void init_MutexAttr();
> >     int m_Count;
> > };
> >
> > /*    TIBMutex.cpp    */
> > TIBMutex::TIBMutex()
> > {
> >  m_Count = 0;
> >  if  (pthread_mutex_init(&m_Mutex, &m_MutexAttr))
> >     /* error handling...*/
> > }
> >
> > inline void TIBMutex::acquire()
> > {
> >  while (m_Count);
> >
> >  if (pthread_mutex_lock(&m_Mutex))
> >  {
> >      /* error handling...*/
> >  }
> >  ++m_Count;
> >  return;
> > }
> >
> > inline void TIBMutex::release()
> > {
> >  if (pthread_mutex_unlock(&m_Mutex))
> >  {
> >     /* error handling...*/
> >  }
> >  --m_Count;
> > }
> >
> > My questions are:
> >
> > 1. Do I need use a condition variable here because I use m_Count as 0/1
> > signal?
> >
> > 2. In the acquire(), when m_Count is not 0, the waiting thread should
> > "spin" there as the above or yield like the following acquire_yield()
> >
> > inline void TIBMutex::acquire_yield()
> > {
> >  while (m_Count)
> >   shed_yield();
> >  if (pthread_mutex_lock(&m_Mutex))
> >  {
> >     /* error handling...*/
> >  }
> >  ++m_Count;
> >  return;
> > }
> >
> >
> > --
> > Ye Liu
> > Tel(O) 650-846-5228
> >
> >
> >

--
Ye Liu
Tel(O) 650-846-5228

Re: critical section

[Scott McCaskill]

----- Original Message -----
From: "Ye Liu" <yliu@tibco.com>
To: "Scott McCaskill" <scott@magruder.org>
Cc: <pthreads-win32@sourceware.cygnus.com>
Sent: Tuesday, July 31, 2001 5:36 PM
Subject: Re: critical section


> In the book of "Programming with POSIX Threads",  the author metioned
>
> "You cannot lock a mutex when the calling thread already has that mutex
locked."
>
> My previous understanding is "a mutex cannot be locked twice", which
obviously
> is wrong.
>
> If I use a non-recursive mutex, when a thread try to lock the mutex which
is
> already locked by another one, what happens to the calling thread? Spin or
> yield?
>

I don't know for sure, but I would expect it to yield.  It seems like the
spinning that your code is doing would be purely wasteful unless the
spinning thread and the mutex-holding thread are on different processors.
Can you give us a better idea of what you're trying to accomplish that
pthread_mutex won't do for you?

catch (...)

[Ye Liu]

Greets,

I have a question on using pthread-win32 in C++:

When I compiling my code with try and catch, I got

"When compiling applications with MSVC++ and C++ exception handling:
  Replace any 'catch( ... )' with 'PtW32CatchAll' in POSIX threads
  if you want POSIX thread cancelation and pthread_exit to work."

in compiling.

May I know what PtW32CatchAll is ? A catch comply certain standard from
Microsoft? I cannot find any information in MSDN. Can someone give me some
details for it?

Regards,

--ye

Re: catch (...)

[Scott McCaskill]

pthreads-win32 uses exceptions to implement thread cancellation.  This means
that, in the threads that you create, if your code (or any code you call)
uses catch(...), it may inadvertantly circumvent this thread cancellation
mechanism.  This is why there is a warning telling you to use PtW32CatchAll
in place of catch(...).

If you look at the bottom of pthread.h, you will see that PtW32CatchAll is
defined as follows:

#define PtW32CatchAll \
        catch( ptw32_exception & ) { throw; } \
        catch( ... )


----- Original Message -----
From: "Ye Liu" <yliu@tibco.com>
To: <pthreads-win32@sourceware.cygnus.com>
Sent: Sunday, August 05, 2001 11:28 PM
Subject: catch (...)


> Greets,
>
> I have a question on using pthread-win32 in C++:
>
> When I compiling my code with try and catch, I got
>
> "When compiling applications with MSVC++ and C++ exception handling:
>   Replace any 'catch( ... )' with 'PtW32CatchAll' in POSIX threads
>   if you want POSIX thread cancelation and pthread_exit to work."
>
> in compiling.
>
> May I know what PtW32CatchAll is ? A catch comply certain standard from
> Microsoft? I cannot find any information in MSDN. Can someone give me some
> details for it?
>
> Regards,
>
> --ye
>
>

Re: catch (...)

[Ye Liu]

Thanks.

--ye

Scott McCaskill wrote:

> pthreads-win32 uses exceptions to implement thread cancellation.  This means
> that, in the threads that you create, if your code (or any code you call)
> uses catch(...), it may inadvertantly circumvent this thread cancellation
> mechanism.  This is why there is a warning telling you to use PtW32CatchAll
> in place of catch(...).
>
> If you look at the bottom of pthread.h, you will see that PtW32CatchAll is
> defined as follows:
>
> #define PtW32CatchAll \
>         catch( ptw32_exception & ) { throw; } \
>         catch( ... )
>
> ----- Original Message -----
> From: "Ye Liu" <yliu@tibco.com>
> To: <pthreads-win32@sourceware.cygnus.com>
> Sent: Sunday, August 05, 2001 11:28 PM
> Subject: catch (...)
>
> > Greets,
> >
> > I have a question on using pthread-win32 in C++:
> >
> > When I compiling my code with try and catch, I got
> >
> > "When compiling applications with MSVC++ and C++ exception handling:
> >   Replace any 'catch( ... )' with 'PtW32CatchAll' in POSIX threads
> >   if you want POSIX thread cancelation and pthread_exit to work."
> >
> > in compiling.
> >
> > May I know what PtW32CatchAll is ? A catch comply certain standard from
> > Microsoft? I cannot find any information in MSDN. Can someone give me some
> > details for it?
> >
> > Regards,
> >
> > --ye
> >
> >

--
Ye Liu
Tel(O) 650-846-5228

Re: catch (...)

[Ross Johnson]

Just to add to Scott's response, there is also a version of the
dll that uses setjmp/longjmp rather than exceptions (thanks
to Thomas Pfaff). It's named pthreadVC.dll, but it doesn't do
any cleanup apart from that done by pthreads cleanup handlers.

Ross

Scott McCaskill wrote:
> 
> pthreads-win32 uses exceptions to implement thread cancellation.  This means
> that, in the threads that you create, if your code (or any code you call)
> uses catch(...), it may inadvertantly circumvent this thread cancellation
> mechanism.  This is why there is a warning telling you to use PtW32CatchAll
> in place of catch(...).
> 
> If you look at the bottom of pthread.h, you will see that PtW32CatchAll is
> defined as follows:
> 
> #define PtW32CatchAll \
>         catch( ptw32_exception & ) { throw; } \
>         catch( ... )
> 
> ----- Original Message -----
> From: "Ye Liu" <yliu@tibco.com>
> To: <pthreads-win32@sourceware.cygnus.com>
> Sent: Sunday, August 05, 2001 11:28 PM
> Subject: catch (...)
> 
> > Greets,
> >
> > I have a question on using pthread-win32 in C++:
> >
> > When I compiling my code with try and catch, I got
> >
> > "When compiling applications with MSVC++ and C++ exception handling:
> >   Replace any 'catch( ... )' with 'PtW32CatchAll' in POSIX threads
> >   if you want POSIX thread cancelation and pthread_exit to work."
> >
> > in compiling.
> >
> > May I know what PtW32CatchAll is ? A catch comply certain standard from
> > Microsoft? I cannot find any information in MSDN. Can someone give me some
> > details for it?
> >
> > Regards,
> >
> > --ye
> >
> >

Re: catch (...)

[reentrant]

> #define PtW32CatchAll \
>         catch( ptw32_exception & ) { throw; } \
>         catch( ... )

Seems like it might be more appropriate (possibly required by the pthread
standard?) for this to have a prefix of "pthread_" and a suffix of "_np" for
non-portable; potentially "pthread_w32_catch_all_np" or similar instead of
"PtW32CatchAll" ?  The same holds true for other PtW32 prefixed items.  It
seems wrong to introduce another namespace.

Dave


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: catch (...)

[Ross Johnson]

reentrant wrote:
> 
> > #define PtW32CatchAll \
> >         catch( ptw32_exception & ) { throw; } \
> >         catch( ... )
> 
> Seems like it might be more appropriate (possibly required by the pthread
> standard?) for this to have a prefix of "pthread_" and a suffix of "_np" for
> non-portable; potentially "pthread_w32_catch_all_np" or similar instead of
>  ?  The same holds true for other PtW32 prefixed items.  It
> seems wrong to introduce another namespace.
> 

You are probably right. If I recall correctly, it was
given a Win32 style name because it is Win32 specific
AND specific to MSVC++. Another weak argument for not putting
it into the _np namespace is that it's a macro standing
in for a compiler keyword rather than imitating a function.

Anyway, changing it now would require people to change their
code.

It can be used portably as follows:

#ifdef PtW32CatchAll
	PtW32CatchAll
#else
	catch(...)
#endif
	{
		// Exception handler of last resort
	}


Or avoid all of this added complexity if you can by using
the plain vanilla C version of the library named pthreadVC.dll
which doesn't use exceptions internally.

Ross