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