From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 21 10:41:12 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F111D1065672 for ; Thu, 21 Jan 2010 10:41:12 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id B01BC8FC14 for ; Thu, 21 Jan 2010 10:41:12 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o0LAf87B029378; Thu, 21 Jan 2010 05:41:08 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Thu, 21 Jan 2010 05:41:08 -0500 (EST) Date: Thu, 21 Jan 2010 05:41:08 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Bernard van Gastel In-Reply-To: <1B4E9B02-AA63-45BF-9BB7-3B0A2884CCB0@bitpowder.com> Message-ID: References: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> <20100119184617.GB50360@dan.emsphone.com> <1B4E9B02-AA63-45BF-9BB7-3B0A2884CCB0@bitpowder.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Dan Nelson Subject: Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 10:41:13 -0000 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