Date: Tue, 27 Apr 2010 14:37:29 -0700 From: "K. Macy" <kmacy@freebsd.org> To: Piotr Honik <piotr.honik@eranet.pl> Cc: freebsd-threads@freebsd.org Subject: Re: Advice / best practice - thread connection pools / mutexes Message-ID: <l2m82c4140e1004271437tcdb2b2ack46adc16a728a86cf@mail.gmail.com> In-Reply-To: <4BD737AA.3000200@eranet.pl> References: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> <4BD737AA.3000200@eranet.pl>
index | next in thread | previous in thread | raw e-mail
I used lock-less ring buffer for passing newly accepted sockets to a thread pool. I can post the code if it is of interest. -Kip On Tue, Apr 27, 2010 at 12:14 PM, Piotr Honik <piotr.honik@eranet.pl> wrote: > 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. > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" >help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l2m82c4140e1004271437tcdb2b2ack46adc16a728a86cf>
