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