Date: Thu, 21 Jan 2010 12:35:10 +0100
From: Pieter de Goeje <pieter@service2media.com>
To: freebsd-hackers@freebsd.org
Cc: Dan Nelson <dnelson@allantgroup.com>
Subject: Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy
Message-ID: <201001211235.10129.pieter@service2media.com>
In-Reply-To: <1B4E9B02-AA63-45BF-9BB7-3B0A2884CCB0@bitpowder.com>
References: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> <20100119184617.GB50360@dan.emsphone.com> <1B4E9B02-AA63-45BF-9BB7-3B0A2884CCB0@bitpowder.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 21 January 2010 11:27:23 Bernard van Gastel wrote:
> In real world application such a proposed queue would work almost always,
> but I'm trying to exclude all starvation situations primarily (speed is
> less relevant). And although such a worker can execute it work and be
> scheduled fairly, the addition of the work to the queue can result in
> starvation (one of the threads trying to add to the queue could stall
> forever if the lock is heavily contested).
This is not possible. The worker threads unlock the mutex during
pthread_cond_wait(). So when the queue is empty, threads can add new items
without blocking.
So for a worker we have:
while(1) {
pthread_mutex_lock(&m)
while(queue_empty()) {
// this atomically unlocks and locks the mutex
pthread_cond_wait(&c, &m)
}
w = fetch_work();
pthread_mutex_unlock(&m);
do_work(&w);
}
And a provider does this:
pthread_mutex_lock(&m);
add_work(&w);
pthread_cond_signal(&c);
pthread_mutex_unlock(&m);
- Pieter de Goeje
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201001211235.10129.pieter>