From owner-freebsd-threads@FreeBSD.ORG Tue Apr 27 08:12:11 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 AC4B81065672 for ; Tue, 27 Apr 2010 08:12:11 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9378FC15 for ; Tue, 27 Apr 2010 08:12:10 +0000 (UTC) Received: from HPQuadro64.dmpriest.net.uk (HPQuadro64.dmpriest.net.uk [62.13.130.30]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/Kp) with ESMTP id o3R80nAw096054 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Apr 2010 09:00:49 +0100 (BST) Date: Tue, 27 Apr 2010 09:00:35 +0100 From: Karl Pielorz To: freebsd-threads@FreeBSD.org Message-ID: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: 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: Tue, 27 Apr 2010 08:12:11 -0000 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