Date: Thu, 21 Jan 2010 05:41:08 -0500 (EST)
From: Daniel Eischen <deischen@freebsd.org>
To: Bernard van Gastel <bvgastel@bitpowder.com>
Cc: freebsd-hackers@freebsd.org, Dan Nelson <dnelson@allantgroup.com>
Subject: Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy
Message-ID: <Pine.GSO.4.64.1001210533090.28344@sea.ntplx.net>
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 Thu, 21 Jan 2010, 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). > > Is this possible with POSIX thread stuff? Or is the only option to use > IPC like message queues for this? I don't see what your problem is if you are using mutexes correctly. Adding or removing work to the queue should be very quick; you lock the mutex, add or remove work to/from the queue, signal the condition variable to wake up any threads waiting for work (when adding work), and unlock the mutex. That's it. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1001210533090.28344>