Date: Wed, 28 Apr 2010 11:23:33 +0100 From: Martin Simmons <martin@lispworks.com> To: freebsd-threads@freebsd.org Subject: Re: Advice / best practice - thread connection pools / mutexes Message-ID: <201004281023.o3SANXJ8017518@higson.cam.lispworks.com> In-Reply-To: <4BD737AA.3000200@eranet.pl> (message from Piotr Honik on Tue, 27 Apr 2010 21:14:50 %2B0200) References: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> <4BD737AA.3000200@eranet.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201004281023.o3SANXJ8017518>