Advice / best practice - thread connection pools / mutexes
Alfred Perlstein
alfred at freebsd.org
Wed Apr 28 11:12:27 UTC 2010
The most simple method is to do the following at startup:
pthread_mutex_t pool_lock = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t pool_cv = PTHREAD_COND_INITIALIZER;
struct conn {
mysql_t socket;
struct conn *next; /* maybe use SLIST? */
} *head;
/* init pool */
for (i = 0; i < MAX_CON; i++) {
conn = malloc(sizeof(*conn));
conn->socket = mysql_connection(...);
conn->next = head;
head = conn;
}
void
queue_con(struct conn *c)
{
conn->next = head;
head = conn;
}
sturct conn *
get_con(void) {
sturct conn *c;
pthread_mutex_lock(pool_lock);
// wait until there's a connection avail
while (head == NULL)
pthread_cond_wait(pool_lock, pool_cv);
// dequeue it
c = head;
head = head->next;
pthead_mutex_unlock(pool_lock);
return (c);
}
void
put_con(sturct conn *c) {
pthread_mutex_lock(pool_lock);
// maybe only if "if (head == NULL)"?
pthead_cond_signal(pool_cv);
queue_con(c);
pthead_mutex_unlock(pool_lock);
}
This should provide for a connection pool, each thread
can then call get_con() to get a connection, and should
call put_con() when done with it.
good luck.
-Alfred
* Karl Pielorz <kpielorz_lst at tdx.co.uk> [100427 01:12] wrote:
>
> Hi,
>
> 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
> connection.
>
> 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
> free one'.
>
> I'm looking at any advice / pointers about how to implement this under
> FreeBSD.
>
> 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
> mutex?
>
> So if anyone's got any advice, pointers - or links to any material/books
> that would help with this, I'd be very grateful...
>
>
> Thanks,
>
> -Karl
> _______________________________________________
> freebsd-threads at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to "freebsd-threads-unsubscribe at freebsd.org"
--
- Alfred Perlstein
.- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10
.- FreeBSD committer
More information about the freebsd-threads
mailing list