Advice / best practice - thread connection pools / mutexes
kpielorz_lst at tdx.co.uk
Tue Apr 27 08:12:11 UTC 2010
We have an application that's threaded using pthreads at the moment under
FreeBSD 6.4. At the moment every thread has it's own (in this case) MySQL
We're looking at changing this due to the volume of connections this
creates (it's not uncommon to have 100+ threads running).
We have another application that's threaded - but only uses a single MySQL
connection (protected by pthread_mutex).
What we'd ideally like is a 'pool' of say 4-8 connections - protected by
mutex, where a thread needing a connection can grab the 'next available
I'm looking at any advice / pointers about how to implement this under
Current thoughts have been:
- Have the code 'try' for a lock on each mutex in turn, if it fails on one
- it moves to the next. This sounds pretty poor - apart from the overhead
of all the trying, there's no guarantee that as you move to mutex #4, mutex
#3 won't free up - and you'll "miss it"
- Use a modulo of the thread ID, which gives us a value of say between 0-3
- and just have the thread try for that particular mutex, and block until
it becomes free. Providing the thread ID's are sequential (which ours are)
it should distribute all the requests around the connection pool.
If three threads try to lock the same mutex - two will block. Is there any
guarantee which order the two blocking ones will get it when the first one
releases it? - Is it FIFO?
What happens if a whole bunch of threads (40?) all try to lock the same
mutex - is there a limit on how many threads can be blocked waiting on a
So if anyone's got any advice, pointers - or links to any material/books
that would help with this, I'd be very grateful...
More information about the freebsd-threads