RE: critical section

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

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?

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]

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

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