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>
next in thread | previous in thread | raw e-mail | index | archive | help
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+ threa= ds > 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: > =A0- the size of =A0the 'pool' controlled easily > =A0- mutexes locked only by one thread > =A0- worker threads don't care about db connection, they only talk to the > manager > =A0- 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= " >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l2m82c4140e1004271437tcdb2b2ack46adc16a728a86cf>