This is the mail archive of the
pthreads-win32@sources.redhat.com
mailing list for the pthreas-win32 project.
RE: critical section
- To: 'Scott McCaskill' <scott at magruder dot org>, Ye Liu <yliu at tibco dot com>
- Subject: RE: critical section
- From: Eli Ofenstein <elio at clearcommerce dot com>
- Date: Tue, 31 Jul 2001 18:07:00 -0500
- Cc: pthreads-win32 at sourceware dot cygnus dot com
> -----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.