This is the mail archive of the pthreads-win32@sources.redhat.com mailing list for the pthreas-win32 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: critical section




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]