Advice / best practice - thread connection pools / mutexes
Martin Simmons
martin at lispworks.com
Wed Apr 28 10:23:36 UTC 2010
>>>>> 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
More information about the freebsd-threads
mailing list