From owner-freebsd-threads@FreeBSD.ORG Wed Apr 28 11:12:26 2010 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4D45106566C for ; Wed, 28 Apr 2010 11:12:26 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B86238FC1F for ; Wed, 28 Apr 2010 11:12:26 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 815F81A3CAA; Wed, 28 Apr 2010 04:12:26 -0700 (PDT) Date: Wed, 28 Apr 2010 04:12:26 -0700 From: Alfred Perlstein To: Karl Pielorz Message-ID: <20100428111226.GK35381@elvis.mu.org> References: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-threads@FreeBSD.org Subject: Re: Advice / best practice - thread connection pools / mutexes X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 11:12:27 -0000 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 [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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer