Unix Programming - Mutex lock/release order?

This is Interesting: Free IT Magazines  
Home > Archive > Unix Programming > April 2004 > Mutex lock/release order?





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Mutex lock/release order?
Daniel Haude

2004-04-19, 11:35 am

Hello,

A short question:

Threads A, B, C, and a mutex. First, thread A locks the mutex, then B
tries to lock it (and blocks), then C (and also blocks). When A now
unlocks the mutex, is it specified (by POSIX) if B gets the mutex before C
does, or is the order in which B and C can lock it unspecified?

Thanks,

--Daniel

--
"With me is nothing wrong! And with you?" (from r.a.m.p)
Måns Rullgård

2004-04-19, 11:35 am

Daniel Haude <haude@physnet.uni-hamburg.de> writes:

> Hello,
>
> A short question:
>
> Threads A, B, C, and a mutex. First, thread A locks the mutex, then B
> tries to lock it (and blocks), then C (and also blocks). When A now
> unlocks the mutex, is it specified (by POSIX) if B gets the mutex before C
> does, or is the order in which B and C can lock it unspecified?


It's undefined, AFAIK. In a wider scheme, there is nothing
determining which of the threads will try to lock the mutex first.
It's all depending on the scheduling of the threads by the OS.

--
Måns Rullgård
mru@kth.se
Eric Sosman

2004-04-19, 11:35 am

Daniel Haude wrote:
>
> Hello,
>
> A short question:
>
> Threads A, B, C, and a mutex. First, thread A locks the mutex, then B
> tries to lock it (and blocks), then C (and also blocks). When A now
> unlocks the mutex, is it specified (by POSIX) if B gets the mutex before C
> does, or is the order in which B and C can lock it unspecified?


Unspecified. In fact, A might re-lock it before
B or C gets a chance. Or D might get into the act and
lock it ahead of B and C and A's attempt to re-lock.

--
Eric.Sosman@sun.com
Mike Chirico

2004-04-19, 4:34 pm


"Daniel Haude" <haude@physnet.uni-hamburg.de> wrote in message
news:slrnc87ql2.qaj.haude@kir.physnet.uni-hamburg.de...
> Hello,
>
> A short question:
>
> Threads A, B, C, and a mutex. First, thread A locks the mutex, then B
> tries to lock it (and blocks), then C (and also blocks). When A now
> unlocks the mutex, is it specified (by POSIX) if B gets the mutex before C
> does, or is the order in which B and C can lock it unspecified?
>
> Thanks,
>
> --Daniel


Actually, the order could be predetermed... A first, followed by B or C,
then back to A.

ABA.. or
ACA.. so A can go first and 3rd. Note, it's given A goes first.

Here's the catch given Pthread_mutex_lock and *Pthread_cond_signal* are
used together.

Here's how.

/* This is thread A which locks first as given in the problem */
Pthread_mutex_lock(&m_mutex)
....does work..
.....then blocks ...
Pthead_cond_wait(&m_cond, &m_mutex);
.... After thread B or C, we don't know which one will get it next, but after
the
.....one of them A will get to run third!
Pthread_mutex_unlock(&m_mutex);


/* Thead B or C, order is unknown would run the following
after A.. But, regardless of which one goes first, A will follow.
*/

Pthread_mutex_lock(&m_mutex);
..... stuff to do
Pthread_cond_signal(&m_cond);
Pthread_mutex_unlock(&m_mutex);


So, this may work without having to use semaphores. Yes, without
Pthread_cond_signal it's unknown.

Regards,

Mike Chirico


Daniel Haude

2004-04-20, 5:34 am

On Mon, 19 Apr 2004 11:17:27 -0400,
Eric Sosman <Eric.Sosman@sun.com> wrote
in Msg. <4083ED87.C0BC938B@sun.com>

> Unspecified. In fact, A might re-lock it before
> B or C gets a chance. Or D might get into the act and
> lock it ahead of B and C and A's attempt to re-lock.



Thanks everybody for the several helpful replies. I'll probably have more
questions coming...

--Daniel

--
"With me is nothing wrong! And with you?" (from r.a.m.p)
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com