From owner-freebsd-threads@FreeBSD.ORG Wed Apr 28 10:23:36 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 3EFFD106564A for ; Wed, 28 Apr 2010 10:23:36 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id CEC818FC13 for ; Wed, 28 Apr 2010 10:23:35 +0000 (UTC) Received: from higson.cam.lispworks.com (IDENT:U2FsdGVkX1/vySD8fNILr/jh2HrH4EQuZKCHNNzsYMM@higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.12.9p2/8.12.9) with ESMTP id o3SANXQc044323; Wed, 28 Apr 2010 11:23:33 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com by higson.cam.lispworks.com (8.13.1) id o3SANXjL017521; Wed, 28 Apr 2010 11:23:33 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.13.1/8.13.1/Submit) id o3SANXJ8017518; Wed, 28 Apr 2010 11:23:33 +0100 Date: Wed, 28 Apr 2010 11:23:33 +0100 Message-Id: <201004281023.o3SANXJ8017518@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-threads@freebsd.org In-reply-to: <4BD737AA.3000200@eranet.pl> (message from Piotr Honik on Tue, 27 Apr 2010 21:14:50 +0200) References: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> <4BD737AA.3000200@eranet.pl> 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: Wed, 28 Apr 2010 10:23:36 -0000 >>>>> On Tue, 27 Apr 2010 21:14:50 +0200, Piotr Honik said: > > 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. The worker threads still have to wait for the results from the database threads, so I don't see how that reduces conditional waiting. If anything, it will add to waiting, because the database threads will be waiting for mysqld to respond. > This approach has several advantages: > - the size of the 'pool' controlled easily > - mutexes locked only by one thread What use is a mutex that is only locked 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 Agreed, those are advantages. __Martin