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

RE: critical section

[Eli Ofenstein]

> -----Original Message-----
> From: Scott McCaskill [ mailto:scott@magruder.org ]
> Sent: Tuesday, July 31, 2001 5:52 PM
> To: Ye Liu
> Cc: pthreads-win32@sourceware.cygnus.com
> Subject: Re: critical section
> 
> 
> ----- 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?
 
That's a big "unless" :)

In many implementations, a hybrid approach is used in which the thread spins
for a period of time before yielding, in order to allow fast critical
sections to complete.  Additionally, implementations are often aware of the
CPU count of the system, and will adopt an immediate-yield policy on single
CPU systems.
 

Re: critical section

[Ye Liu]

You suggest that I leave it to the system decide whether "spin" or "yield". Is
there a function in pthread to decide how many processors the system has?

--ye

Eli Ofenstein wrote:

> > -----Original Message-----
> > From: Scott McCaskill [ mailto:scott@magruder.org ]
> > Sent: Tuesday, July 31, 2001 5:52 PM
> > To: Ye Liu
> > Cc: pthreads-win32@sourceware.cygnus.com
> > Subject: Re: critical section
> >
> >
> > ----- 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?
>
> That's a big "unless" :)
>
> In many implementations, a hybrid approach is used in which the thread spins
> for a period of time before yielding, in order to allow fast critical
> sections to complete.  Additionally, implementations are often aware of the
> CPU count of the system, and will adopt an immediate-yield policy on single
> CPU systems.
>

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

Re: critical section

[Ross Johnson]

Eli Ofenstein wrote:
> 
> > -----Original Message-----
> > From: Scott McCaskill [ mailto:scott@magruder.org ]
> > Sent: Tuesday, July 31, 2001 5:52 PM
> > To: Ye Liu
> > Cc: pthreads-win32@sourceware.cygnus.com
> > Subject: Re: critical section
> >
> >
> > ----- 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.

The quote from the book is describing a special case and your previous
understanding is correct generally for non-recursive mutexes.

> > >
> > > 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?
> 
> That's a big "unless" :)
> 
> In many implementations, a hybrid approach is used in which the thread spins
> for a period of time before yielding, in order to allow fast critical
> sections to complete.  Additionally, implementations are often aware of the
> CPU count of the system, and will adopt an immediate-yield policy on single
> CPU systems.
> 

The pthread_mutex_* routines follow the Open Group specification
manual page at:

(the following URL is all one line)

http://www.rtlinux.org/documents/documentation/man_pages/susv2/xsh/pthread_mutex_lock.html

Those in pthreads-win32 don't spin. However, the latest
pthreads-win32 snapshot includes the following specialised
spinlock functions:

pthread_spin_init
pthread_spin_destroy
pthread_spin_lock
pthread_spin_unlock
pthread_spin_trylock
and
PTHREAD_SPINLOCK_INITIALIZER

POSIX_SPIN_LOCKS is defined.

These are CPU affinity mask-aware and do do an immediate yield
when used in single CPU processes (even on multi-CPU systems),
spinning otherwise.

Note that, in accordance with the POSIX 1003.1j standard, these
routines don't yield after a predefined spin count. They are
intended to be used for very short duration critical sections
[on multi-CPU systems].

These routines have been tested on a single CPU system but
not yet on a multi-CPU system. If someone is able to do that
I would like to know of any problems that arise (there is
a group of programs already written for this purpose in the
"tests" directory - called spin*.c).

Hope this helps.
Ross

-- 
+-------------------------+---+
| Ross Johnson            |   | "Come down off the cross
| Management & Technology |___|  We can use the wood" - Tom Waits
| Building 11                 |
| University of Canberra      | eMail: rpj@ise.canberra.edu.au
| ACT    2601                 | WWW:  
http://public.ise.canberra.edu.au/~rpj/
| AUSTRALIA                   |
+-----------------------------+