From owner-freebsd-threads@FreeBSD.ORG Tue Apr 27 20:14:54 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79AC31065672 for ; Tue, 27 Apr 2010 20:14:54 +0000 (UTC) (envelope-from piotr.honik@eranet.pl) Received: from mta.eranet.pl (mta.eranet.pl [213.158.194.142]) by mx1.freebsd.org (Postfix) with ESMTP id 35EDF8FC19 for ; Tue, 27 Apr 2010 20:14:53 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [10.16.0.50] ([89.73.124.75]) by eranet.pl (Sun Java(tm) System Messaging Server 6.3-8.04 (built Jul 29 2009; 32bit)) with ESMTPSA id <0L1J00AV2USQJ270@eranet.pl> for freebsd-threads@freebsd.org; Tue, 27 Apr 2010 21:14:51 +0200 (CEST) Sender: mac@eranet.pl Message-id: <4BD737AA.3000200@eranet.pl> Date: Tue, 27 Apr 2010 21:14:50 +0200 From: Piotr Honik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 To: freebsd-threads@freebsd.org References: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> In-reply-to: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> X-Mailman-Approved-At: Tue, 27 Apr 2010 21:35:47 +0000 Subject: Re: Advice / best practice - thread connection pools / mutexes X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 20:14:54 -0000 Why don't you consider implementing a full manager-worker model? Tracking multiple mutexes and conditional waiting when you hit 100+ threads isn't going to give you good performance. I would be looking at a separate thread doing one thing only - performing database queries on behalf of worker threads. This approach has several advantages: - the size of the 'pool' controlled easily - mutexes locked only by one thread - worker threads don't care about db connection, they only talk to the manager - good starting point to develop a complete round-robin solution with several db servers PH.