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)

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

"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 afte
r
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

[ Post a follow-up to this message ]

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)

[ Post a follow-up to this message ]