newbie question about threads
glubutz
I've got two threads running with these functions, they change a global
integer and display it (see functions below)
Why does a thread unlocks the mutex then can lock it again ? What about the
other one waiting ?
I thought they would work one after another ...
Sometimes it's thread1, then thread 2 that keeps locking/unlocking/locking
...
I thought I would get after a while:
thread1 working
thread2 working
thread1 working
thread2 working
thread1 working
thread2 working
and not
thread1 working
thread1 working
thread1 working
...
thread2 working
thread2 working
thread2 working
...
thread1 working
thread2 working
thread1 working
thread2 working
...
thread1 working
thread1 working
thread1 working
...
Thanks for your answers !
functions :
----------
for thread 1 :
void *
){
while(1) {
lock the mutex
count++;
printf("%d\n",count)
unlock the mutex
}
}
for thread 2 :
void * f2(){
while(1) {
lock the mutex
count--;
printf("%d\n",count)
unlock the mutex
}
}
David Schwartz
glubutz wrote:
>
> Hi,
>
> I've got two threads running with these functions, they change a global
> integer and display it (see functions below)
> Why does a thread unlocks the mutex then can lock it again ? What about the
> other one waiting ?
>
> I thought they would work one after another ...
> Sometimes it's thread1, then thread 2 that keeps locking/unlocking/locking
> ...
Why would you think that? Why would expect the system to choose the
most inefficient possible arrangement? (The one that requires the most
context switches.)
DS
glubutz
3ACB572D...@webmaster.com...
I thought it would work like that :
Thread A locks the mutex
* Thread B is waiting mutex to be unlocked ....
Thread A unlocks the mutex
-> Thread B can now lock the mutex....
* Thread A is waiting mutex to be unlocked ....
.......
So the fact that thread B was waiting doesn't make it have priority on the
mutex ?
Michael D. Beynon
> Thread A locks the mutex
> * Thread B is waiting mutex to be unlocked ....
> Thread A unlocks the mutex
> -> Thread B can now lock the mutex....
> * Thread A is waiting mutex to be unlocked ....
> .......
>
> So the fact that thread B was waiting doesn't make it have priority on the
> mutex ?
If you were running on an SMP with 2+ processors, you may very well
see what you were expecting (or something close to it), because your
threads reall are concurrent. The problem with this expectation on a
single processor machine is that threads are timesliced by the pthreads
scheduler. Consider the following scenario: the first thread starts and
is scheduled to run. Perhaps now the second thread is created and
is waiting to run. The first thread locks the mutex, increments, and unlocks
the mutex. When it is done, there may still be time left in its timeslice,
so the loop repeats. Now some time later the second thread can be
scheduled, and it gets a change to run for a while. There is even the
possibility that when the second thread starts, the first thread still owns
the mutex, in which case the second thread will block on the mutex and
the first thread will start running again. The default pthreads scheduler
operates using coarse timeslices to avoid (as DS said) to avoid context
switch costs.
Mike.
Dave Butenhof
Right.
There are two strategies one could choose here: fairness, and throughput.
Given throughput, one can construct ones own fairness (by whatever metric one
chooses to judge the term, and there are many). Given "fairness" (and, worse,
one person's judgement of "fairness"), one cannot easily construct on top of
that a fast implementation to allow better throughput... nor, in general, a
different version of "fairness".
POSIX synchronization is not intended to be fair. It's intended to be
efficient and general. So that, if you really want fairness, you can make it;
and, if not, you don't have to pay for it. As David Schwartz said, "fairness"
in this situation is the worst possible performance.
Threads are intended to be PARTNERS, not COMPETITORS. You're trying to get a
job done, efficiently. If one thread is already running, and wants the mutex,
it SHOULD take the mutex rather than block to let some other thread start up
and take it. An application designed to depend on "fairness" isn't correct or
portable.
If you insist on writing a competitive threaded application, instead of the
generally better strategy of trying for a cooperative application, you'll need
to make your own fairness. This unfortunately is fairly common in servers,
because "thread per client" servers seem natural and easy. (They just don't
perform well with many clients, because they're inherently competitive, and
they share too many resources to compete "nonviolently".) A better strategy is
to shift to a "work crew" model, where client requests are handled by a small
pool of anonymous threads (that aren't tied to a given client). The client
fairness comes from the ordering of the work items handed to the work crew,
rather than from trying to force "fair" (and expensive) synchronization and
scheduling on the threads.
/------------------[ David.B...@compaq.com ]------------------\
| Compaq Computer Corporation POSIX Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/
glubutz
David Schwartz
glubutz wrote:
> I thought it would work like that :
> Thread A locks the mutex
> * Thread B is waiting mutex to be unlocked ....
> Thread A unlocks the mutex
> -> Thread B can now lock the mutex....
> * Thread A is waiting mutex to be unlocked ....
> .......
That would be horrible. That would give the absolute worst possible
performance (on typical platforms, assuming a single CPU).
> So the fact that thread B was waiting doesn't make it have priority on the
> mutex ?
No. The fact that thread A is *running*, hasn't used up all of its
timeslice, and doesn't require any additional resources from the system
makes the operating system want to keep it running if at all possible.
There is no logical reason for the system to steal the rest of thread
A's timeslice away from it.
At least, this is so in most implementations. The standard doesn't
require any particular type of behavior.
DS