From owner-freebsd-threads@FreeBSD.ORG Sun Apr 25 11:26:13 2010 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED8D1106566C; Sun, 25 Apr 2010 11:26:13 +0000 (UTC) (envelope-from jilles@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C47DB8FC1B; Sun, 25 Apr 2010 11:26:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3PBQD2r036175; Sun, 25 Apr 2010 11:26:13 GMT (envelope-from jilles@freefall.freebsd.org) Received: (from jilles@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3PBQCqK036171; Sun, 25 Apr 2010 11:26:12 GMT (envelope-from jilles) Date: Sun, 25 Apr 2010 11:26:12 GMT Message-Id: <201004251126.o3PBQCqK036171@freefall.freebsd.org> To: m.hekkelman@cmbi.kun.nl, jilles@FreeBSD.org, freebsd-threads@FreeBSD.org From: jilles@FreeBSD.org Cc: Subject: Re: threads/70975: [sysvipc] unexpected and unreliable behaviour when using SYSV semaphore, fork and pipe 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: Sun, 25 Apr 2010 11:26:14 -0000 Synopsis: [sysvipc] unexpected and unreliable behaviour when using SYSV semaphore, fork and pipe State-Changed-From-To: open->closed State-Changed-By: jilles State-Changed-When: Sun Apr 25 11:26:12 UTC 2010 State-Changed-Why: The problem is that with libc_r SysV semaphores will block the entire process. We are sorry that this will not be fixed in libc_r, but the newer threading libraries do not have this problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=70975 From owner-freebsd-threads@FreeBSD.ORG Mon Apr 26 11:07: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 1DFD31065679 for ; Mon, 26 Apr 2010 11:07:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0BBF28FC1F for ; Mon, 26 Apr 2010 11:07:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3QB7A2p004294 for ; Mon, 26 Apr 2010 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3QB7AQx004292 for freebsd-threads@FreeBSD.org; Mon, 26 Apr 2010 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Apr 2010 11:07:10 GMT Message-Id: <201004261107.o3QB7AQx004292@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org 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: Mon, 26 Apr 2010 11:07:11 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/143115 threads [patch] pthread_join() can return EOPNOTSUPP o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/141198 threads [libc] src/lib/libc/stdio does not properly initialize o threa/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 p threa/135462 threads [PATCH] _thread_cleanupspecific() doesn't handle delet o threa/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 42 problems total. 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 From owner-freebsd-threads@FreeBSD.ORG Tue Apr 27 10:18:09 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 A35961065674 for ; Tue, 27 Apr 2010 10:18:09 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id 419028FC0A for ; Tue, 27 Apr 2010 10:18:08 +0000 (UTC) Received: from higson.cam.lispworks.com (IDENT:U2FsdGVkX18d9lOEAi+VV8iePQUTCyoB5p/xw+YkaWk@higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.12.9p2/8.12.9) with ESMTP id o3RA7oQc047811; Tue, 27 Apr 2010 11:07:50 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com by higson.cam.lispworks.com (8.13.1) id o3RA7o0F021470; Tue, 27 Apr 2010 11:07:50 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.13.1/8.13.1/Submit) id o3RA7nLK021467; Tue, 27 Apr 2010 11:07:49 +0100 Date: Tue, 27 Apr 2010 11:07:49 +0100 Message-Id: <201004271007.o3RA7nLK021467@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-threads@freebsd.org In-reply-to: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> (message from Karl Pielorz on Tue, 27 Apr 2010 09:00:35 +0100) References: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> 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: Tue, 27 Apr 2010 10:18:09 -0000 Assuming it is safe share MySQL connections between threads like that (I don't know), then using a data structure to track the unused connections sounds like the simplest approach. Protect access to the data structure with a mutex and use a condition variable to wait (with pthread_cond_wait) for a free connection if they are all in use. When a connection is freed, use pthread_cond_signal to wake a waiting thread. Note that both pthread_cond_wait and pthread_cond_signal must be called while holding the mutex to prevent missed wakups. __Martin From owner-freebsd-threads@FreeBSD.ORG Tue Apr 27 20:14:54 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 79AC31065672 for ; Tue, 27 Apr 2010 20:14:54 +0000 (UTC) (envelope-from piotr.honik@eranet.pl) Received: from mta.eranet.pl (mta.eranet.pl [213.158.194.142]) by mx1.freebsd.org (Postfix) with ESMTP id 35EDF8FC19 for ; Tue, 27 Apr 2010 20:14:53 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [10.16.0.50] ([89.73.124.75]) by eranet.pl (Sun Java(tm) System Messaging Server 6.3-8.04 (built Jul 29 2009; 32bit)) with ESMTPSA id <0L1J00AV2USQJ270@eranet.pl> for freebsd-threads@freebsd.org; Tue, 27 Apr 2010 21:14:51 +0200 (CEST) Sender: mac@eranet.pl Message-id: <4BD737AA.3000200@eranet.pl> Date: Tue, 27 Apr 2010 21:14:50 +0200 From: Piotr Honik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 To: freebsd-threads@freebsd.org References: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> In-reply-to: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> X-Mailman-Approved-At: Tue, 27 Apr 2010 21:35:47 +0000 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: Tue, 27 Apr 2010 20:14:54 -0000 Why don't you consider implementing a full manager-worker model? Tracking multiple mutexes and conditional waiting when you hit 100+ threads isn't going to give you good performance. I would be looking at a separate thread doing one thing only - performing database queries on behalf of worker threads. This approach has several advantages: - the size of the 'pool' controlled easily - mutexes locked only by one thread - worker threads don't care about db connection, they only talk to the manager - good starting point to develop a complete round-robin solution with several db servers PH. From owner-freebsd-threads@FreeBSD.ORG Tue Apr 27 22:01:15 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 54C4C106566B for ; Tue, 27 Apr 2010 22:01:15 +0000 (UTC) (envelope-from kmatthew.macy@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 0CB9B8FC1D for ; Tue, 27 Apr 2010 22:01:14 +0000 (UTC) Received: by qyk11 with SMTP id 11so17217207qyk.13 for ; Tue, 27 Apr 2010 15:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=n+4y38ZQQlJ2GxLZb+MwgqIte2x+OjR0AOVFvrmmiqE=; b=Qnuhr5Ddi6FrQgttA/sRVtJSYjY72qvFEYa+UDYJbYbVpbVIboqQd8QWrF6u9RB0CC 4R6okDq+n8irSfiIpQhgkXyYhPOk2iGEYi5Z2OjwWGQX0VBqyh6zca9N5A0Qvwjo/mGi Jn8pW36CFe5ZKuPmmW5AhegvtHQmgKkE80cAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=uJhrN0Yyx8+NzfWeDq9jaC3wRhoXEtMdxOMQQJM+jXcdUzH1cex7XuQvIfET5pNu+K U7WMvnjTEZ32HIkPt1f0GPyoDzj7xQCZGGeLgtCF/4y5GP3L5Jt1v+F+vTnhYyBqPIZr wpJoFOiM8oG3Yj9Hp/xCxJcasU5EQH+TRjxzk= MIME-Version: 1.0 Received: by 10.229.226.1 with SMTP id iu1mr8172259qcb.19.1272404249682; Tue, 27 Apr 2010 14:37:29 -0700 (PDT) Sender: kmatthew.macy@gmail.com Received: by 10.229.231.18 with HTTP; Tue, 27 Apr 2010 14:37:29 -0700 (PDT) In-Reply-To: <4BD737AA.3000200@eranet.pl> References: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> <4BD737AA.3000200@eranet.pl> Date: Tue, 27 Apr 2010 14:37:29 -0700 X-Google-Sender-Auth: 14381f6dd4aa9693 Message-ID: From: "K. Macy" To: Piotr Honik Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 Reply-To: kmacy@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 22:01:15 -0000 I used lock-less ring buffer for passing newly accepted sockets to a thread pool. I can post the code if it is of interest. -Kip On Tue, Apr 27, 2010 at 12:14 PM, Piotr Honik wrote= : > Why don't you consider implementing a full manager-worker model? > Tracking multiple mutexes and conditional waiting when you hit 100+ threa= ds > isn't going to give you good performance. > I would be looking at a separate thread doing one thing only - performing > database queries on behalf of worker threads. > > This approach has several advantages: > =A0- the size of =A0the 'pool' controlled easily > =A0- mutexes locked only by one thread > =A0- worker threads don't care about db connection, they only talk to the > manager > =A0- good starting point to develop a complete round-robin solution with > several db servers > > PH. > _______________________________________________ > 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= " > From owner-freebsd-threads@FreeBSD.ORG Tue Apr 27 22:19:29 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 BCDCD106566B; Tue, 27 Apr 2010 22:19:29 +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 AC9828FC0C; Tue, 27 Apr 2010 22:19:29 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id A49C71A3C41; Tue, 27 Apr 2010 15:05:42 -0700 (PDT) Date: Tue, 27 Apr 2010 15:05:42 -0700 From: Alfred Perlstein To: "K. Macy" Message-ID: <20100427220542.GH35381@elvis.mu.org> References: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> <4BD737AA.3000200@eranet.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Piotr Honik , 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: Tue, 27 Apr 2010 22:19:29 -0000 * K. Macy [100427 15:01] wrote: > I used lock-less ring buffer for passing newly accepted sockets to a > thread pool. > > I can post the code if it is of interest. That would be very interesting! please do. > > > On Tue, Apr 27, 2010 at 12:14 PM, Piotr Honik wrote: > > Why don't you consider implementing a full manager-worker model? > > Tracking multiple mutexes and conditional waiting when you hit 100+ threads > > isn't going to give you good performance. > > I would be looking at a separate thread doing one thing only - performing > > database queries on behalf of worker threads. > > > > This approach has several advantages: > > ?- the size of ?the 'pool' controlled easily > > ?- mutexes locked only by one thread > > ?- worker threads don't care about db connection, they only talk to the > > manager > > ?- good starting point to develop a complete round-robin solution with > > several db servers > > > > PH. > > _______________________________________________ > > 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" > > > _______________________________________________ > 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 From owner-freebsd-threads@FreeBSD.ORG Wed Apr 28 10:23:36 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 3EFFD106564A for ; Wed, 28 Apr 2010 10:23:36 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id CEC818FC13 for ; Wed, 28 Apr 2010 10:23:35 +0000 (UTC) Received: from higson.cam.lispworks.com (IDENT:U2FsdGVkX1/vySD8fNILr/jh2HrH4EQuZKCHNNzsYMM@higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.12.9p2/8.12.9) with ESMTP id o3SANXQc044323; Wed, 28 Apr 2010 11:23:33 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com by higson.cam.lispworks.com (8.13.1) id o3SANXjL017521; Wed, 28 Apr 2010 11:23:33 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.13.1/8.13.1/Submit) id o3SANXJ8017518; Wed, 28 Apr 2010 11:23:33 +0100 Date: Wed, 28 Apr 2010 11:23:33 +0100 Message-Id: <201004281023.o3SANXJ8017518@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-threads@freebsd.org In-reply-to: <4BD737AA.3000200@eranet.pl> (message from Piotr Honik on Tue, 27 Apr 2010 21:14:50 +0200) References: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> <4BD737AA.3000200@eranet.pl> 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 10:23:36 -0000 >>>>> On Tue, 27 Apr 2010 21:14:50 +0200, Piotr Honik said: > > Why don't you consider implementing a full manager-worker model? > Tracking multiple mutexes and conditional waiting when you hit 100+ > threads isn't going to give you good performance. > I would be looking at a separate thread doing one thing only - > performing database queries on behalf of worker threads. The worker threads still have to wait for the results from the database threads, so I don't see how that reduces conditional waiting. If anything, it will add to waiting, because the database threads will be waiting for mysqld to respond. > This approach has several advantages: > - the size of the 'pool' controlled easily > - mutexes locked only by one thread What use is a mutex that is only locked by one thread?! > - worker threads don't care about db connection, they only talk to the > manager > - good starting point to develop a complete round-robin solution with > several db servers Agreed, those are advantages. __Martin 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 From owner-freebsd-threads@FreeBSD.ORG Wed Apr 28 11:56:00 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 7BDB31065686; Wed, 28 Apr 2010 11:56:00 +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 175AA8FC08; Wed, 28 Apr 2010 11:55:59 +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 o3SBtw5C035997 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 28 Apr 2010 12:55:58 +0100 (BST) Date: Wed, 28 Apr 2010 12:55:38 +0100 From: Karl Pielorz To: Alfred Perlstein Message-ID: In-Reply-To: <20100428111226.GK35381@elvis.mu.org> References: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> <20100428111226.GK35381@elvis.mu.org> 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: 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:56:00 -0000 --On 28 April 2010 04:12 -0700 Alfred Perlstein wrote: > The most simple method is to do the following at startup: > > [snip wonderful sample code] > > 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 Thanks, that looks pretty much exactly what I'm looking for - thanks also to the other people who replied, I've certainly got a few options now (which is a big improvement on what I had before!). Regards, -Karl From owner-freebsd-threads@FreeBSD.ORG Wed Apr 28 14:11:09 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 79651106564A for ; Wed, 28 Apr 2010 14:11:09 +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 6889E8FC13 for ; Wed, 28 Apr 2010 14:11:09 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 4BDB11A3D3B; Wed, 28 Apr 2010 07:11:09 -0700 (PDT) Date: Wed, 28 Apr 2010 07:11:09 -0700 From: Alfred Perlstein To: Karl Pielorz Message-ID: <20100428141109.GL35381@elvis.mu.org> References: <6AD0A971B01FA1DE632BAF65@HPQuadro64.dmpriest.net.uk> <20100428111226.GK35381@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 14:11:09 -0000 * Karl Pielorz [100428 04:56] wrote: > > --On 28 April 2010 04:12 -0700 Alfred Perlstein wrote: > > >The most simple method is to do the following at startup: > > > >[snip wonderful sample code] > > > >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 > > Thanks, that looks pretty much exactly what I'm looking for - thanks also > to the other people who replied, I've certainly got a few options now > (which is a big improvement on what I had before!). I'd keep an eye out for Kip's version, it's likely to be a lot faster. :) -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-threads@FreeBSD.ORG Wed Apr 28 15:40:05 2010 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17F2E106566B for ; Wed, 28 Apr 2010 15:40:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E0E278FC15 for ; Wed, 28 Apr 2010 15:40:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3SFe4c8030279 for ; Wed, 28 Apr 2010 15:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3SFe4v4030277; Wed, 28 Apr 2010 15:40:04 GMT (envelope-from gnats) Date: Wed, 28 Apr 2010 15:40:04 GMT Message-Id: <201004281540.o3SFe4v4030277@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: threads/116181: commit references a PR X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 15:40:05 -0000 The following reply was made to PR threads/116181; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: threads/116181: commit references a PR Date: Wed, 28 Apr 2010 15:38:11 +0000 (UTC) Author: attilio Date: Wed Apr 28 15:38:01 2010 New Revision: 207329 URL: http://svn.freebsd.org/changeset/base/207329 Log: - Extract the IODEV_PIO interface from ia64 and make it MI. In the end, it does help fixing /dev/io usage from multithreaded processes. - On i386 and amd64 the old behaviour is kept but multithreaded processes must use the new interface in order to work well. - Support for the other architectures is greatly improved, where necessary, by the necessity to define very small things now. Manpage update will happen shortly. Sponsored by: Sandvine Incorporated PR: threads/116181 Reviewed by: emaste, marcel MFC after: 3 weeks Added: head/sys/dev/io/iodev.h (contents, props changed) Modified: head/sys/amd64/amd64/io.c head/sys/amd64/include/iodev.h head/sys/dev/io/iodev.c head/sys/i386/i386/io.c head/sys/i386/include/iodev.h head/sys/ia64/ia64/iodev_machdep.c head/sys/ia64/include/iodev.h Modified: head/sys/amd64/amd64/io.c ============================================================================== --- head/sys/amd64/amd64/io.c Wed Apr 28 15:15:06 2010 (r207328) +++ head/sys/amd64/amd64/io.c Wed Apr 28 15:38:01 2010 (r207329) @@ -28,60 +28,32 @@ __FBSDID("$FreeBSD$"); #include -#include -#include -#include -#include -#include -#include #include -#include -#include -#include #include -#include -#include - -#include -#include - #include +#include -/* ARGSUSED */ int -ioopen(struct cdev *dev __unused, int flags __unused, int fmt __unused, - struct thread *td) +iodev_open(struct thread *td) { - int error; - - error = priv_check(td, PRIV_IO); - if (error != 0) - return (error); - error = securelevel_gt(td->td_ucred, 0); - if (error != 0) - return (error); td->td_frame->tf_rflags |= PSL_IOPL; - return (0); } -/* ARGSUSED */ int -ioclose(struct cdev *dev __unused, int flags __unused, int fmt __unused, - struct thread *td) +iodev_close(struct thread *td) { - td->td_frame->tf_rflags &= ~PSL_IOPL; + td->td_frame->tf_rflags &= ~PSL_IOPL; return (0); } /* ARGSUSED */ int -ioioctl(struct cdev *dev __unused, u_long cmd __unused, caddr_t data __unused, - int fflag __unused, struct thread *td __unused) +iodev_ioctl(u_long cmd __unused, caddr_t data __unused) { - return (ENXIO); + return (ENOIOCTL); } Modified: head/sys/amd64/include/iodev.h ============================================================================== --- head/sys/amd64/include/iodev.h Wed Apr 28 15:15:06 2010 (r207328) +++ head/sys/amd64/include/iodev.h Wed Apr 28 15:38:01 2010 (r207329) @@ -25,7 +25,22 @@ * * $FreeBSD$ */ +#ifndef _MACHINE_IODEV_H_ +#define _MACHINE_IODEV_H_ -d_open_t ioopen; -d_close_t ioclose; -d_ioctl_t ioioctl; +#ifdef _KERNEL +#include + +#define iodev_read_1 inb +#define iodev_read_2 inw +#define iodev_read_4 inl +#define iodev_write_1 outb +#define iodev_write_2 outw +#define iodev_write_4 outl + +int iodev_open(struct thread *td); +int iodev_close(struct thread *td); +int iodev_ioctl(u_long cmd, caddr_t data); + +#endif /* _KERNEL */ +#endif /* _MACHINE_IODEV_H_ */ Modified: head/sys/dev/io/iodev.c ============================================================================== --- head/sys/dev/io/iodev.c Wed Apr 28 15:15:06 2010 (r207328) +++ head/sys/dev/io/iodev.c Wed Apr 28 15:38:01 2010 (r207329) @@ -30,22 +30,27 @@ __FBSDID("$FreeBSD$"); #include #include -#include #include -#include -#include +#include #include -#include +#include #include -#include #include -#include - -#include -#include #include +#include + +static int ioopen(struct cdev *dev, int flags, int fmt, + struct thread *td); +static int ioclose(struct cdev *dev, int flags, int fmt, + struct thread *td); +static int ioioctl(struct cdev *dev, u_long cmd, caddr_t data, + int fflag, struct thread *td); + +static int iopio_read(struct iodev_pio_req *req); +static int iopio_write(struct iodev_pio_req *req); + static struct cdev *iodev; static struct cdevsw io_cdevsw = { @@ -58,6 +63,129 @@ static struct cdevsw io_cdevsw = { /* ARGSUSED */ static int +ioopen(struct cdev *dev __unused, int flags __unused, int fmt __unused, + struct thread *td) +{ + int error; + + error = priv_check(td, PRIV_IO); + if (error != 0) + return (error); + error = securelevel_gt(td->td_ucred, 0); + if (error != 0) + return (error); + error = iodev_open(td); + + return (error); +} + +/* ARGSUSED */ +static int +ioclose(struct cdev *dev __unused, int flags __unused, int fmt __unused, + struct thread *td) +{ + + return (iodev_close(td)); +} + +/* ARGSUSED */ +static int +ioioctl(struct cdev *dev __unused, u_long cmd, caddr_t data, + int fflag __unused, struct thread *td __unused) +{ + struct iodev_pio_req *pio_req; + int error; + + switch (cmd) { + case IODEV_PIO: + pio_req = (struct iodev_pio_req *)data; + switch (pio_req->access) { + case IODEV_PIO_READ: + error = iopio_read(pio_req); + break; + case IODEV_PIO_WRITE: + error = iopio_write(pio_req); + break; + default: + error = EINVAL; + break; + } + break; + default: + error = iodev_ioctl(cmd, data); + } + + return (error); +} + +static int +iopio_read(struct iodev_pio_req *req) +{ + + switch (req->width) { + case 1: + req->val = iodev_read_1(req->port); + break; + case 2: + if (req->port & 1) { + req->val = iodev_read_1(req->port); + req->val |= iodev_read_1(req->port + 1) << 8; + } else + req->val = iodev_read_2(req->port); + break; + case 4: + if (req->port & 1) { + req->val = iodev_read_1(req->port); + req->val |= iodev_read_2(req->port + 1) << 8; + req->val |= iodev_read_1(req->port + 3) << 24; + } else if (req->port & 2) { + req->val = iodev_read_2(req->port); + req->val |= iodev_read_2(req->port + 2) << 16; + } else + req->val = iodev_read_4(req->port); + break; + default: + return (EINVAL); + } + + return (0); +} + +static int +iopio_write(struct iodev_pio_req *req) +{ + + switch (req->width) { + case 1: + iodev_write_1(req->port, req->val); + break; + case 2: + if (req->port & 1) { + iodev_write_1(req->port, req->val); + iodev_write_1(req->port + 1, req->val >> 8); + } else + iodev_write_2(req->port, req->val); + break; + case 4: + if (req->port & 1) { + iodev_write_1(req->port, req->val); + iodev_write_2(req->port + 1, req->val >> 8); + iodev_write_1(req->port + 3, req->val >> 24); + } else if (req->port & 2) { + iodev_write_2(req->port, req->val); + iodev_write_2(req->port + 2, req->val >> 16); + } else + iodev_write_4(req->port, req->val); + break; + default: + return (EINVAL); + } + + return (0); +} + +/* ARGSUSED */ +static int io_modevent(module_t mod __unused, int type, void *data __unused) { switch(type) { Added: head/sys/dev/io/iodev.h ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/sys/dev/io/iodev.h Wed Apr 28 15:38:01 2010 (r207329) @@ -0,0 +1,44 @@ +/*- + * Copyright (c) 2010 Marcel Moolenaar + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _DEV_IODEV_H_ +#define _DEV_IODEV_H_ + +#define IODEV_PIO_READ 0 +#define IODEV_PIO_WRITE 1 + +struct iodev_pio_req { + u_int access; + u_int port; + u_int width; + u_int val; +}; + +#define IODEV_PIO _IOWR('I', 0, struct iodev_pio_req) + +#endif /* _DEV_IODEV_H_ */ Modified: head/sys/i386/i386/io.c ============================================================================== --- head/sys/i386/i386/io.c Wed Apr 28 15:15:06 2010 (r207328) +++ head/sys/i386/i386/io.c Wed Apr 28 15:38:01 2010 (r207329) @@ -28,60 +28,32 @@ __FBSDID("$FreeBSD$"); #include -#include -#include -#include -#include -#include -#include #include -#include -#include -#include #include -#include -#include - -#include -#include - #include +#include -/* ARGSUSED */ int -ioopen(struct cdev *dev __unused, int flags __unused, int fmt __unused, - struct thread *td) +iodev_open(struct thread *td) { - int error; - - error = priv_check(td, PRIV_IO); - if (error != 0) - return (error); - error = securelevel_gt(td->td_ucred, 0); - if (error != 0) - return (error); td->td_frame->tf_eflags |= PSL_IOPL; - return (0); } -/* ARGSUSED */ int -ioclose(struct cdev *dev __unused, int flags __unused, int fmt __unused, - struct thread *td) +iodev_close(struct thread *td) { - td->td_frame->tf_eflags &= ~PSL_IOPL; + td->td_frame->tf_eflags &= ~PSL_IOPL; return (0); } /* ARGSUSED */ int -ioioctl(struct cdev *dev __unused, u_long cmd __unused, caddr_t data __unused, - int fflag __unused, struct thread *td __unused) +iodev_ioctl(u_long cmd __unused, caddr_t data __unused) { - return (ENXIO); + return (ENOIOCTL); } Modified: head/sys/i386/include/iodev.h ============================================================================== --- head/sys/i386/include/iodev.h Wed Apr 28 15:15:06 2010 (r207328) +++ head/sys/i386/include/iodev.h Wed Apr 28 15:38:01 2010 (r207329) @@ -25,7 +25,22 @@ * * $FreeBSD$ */ +#ifndef _MACHINE_IODEV_H_ +#define _MACHINE_IODEV_H_ -d_open_t ioopen; -d_close_t ioclose; -d_ioctl_t ioioctl; +#ifdef _KERNEL +#include + +#define iodev_read_1 inb +#define iodev_read_2 inw +#define iodev_read_4 inl +#define iodev_write_1 outb +#define iodev_write_2 outw +#define iodev_write_4 outl + +int iodev_open(struct thread *td); +int iodev_close(struct thread *td); +int iodev_ioctl(u_long cmd, caddr_t data); + +#endif /* _KERNEL */ +#endif /* _MACHINE_IODEV_H_ */ Modified: head/sys/ia64/ia64/iodev_machdep.c ============================================================================== --- head/sys/ia64/ia64/iodev_machdep.c Wed Apr 28 15:15:06 2010 (r207328) +++ head/sys/ia64/ia64/iodev_machdep.c Wed Apr 28 15:38:01 2010 (r207329) @@ -40,61 +40,33 @@ __FBSDID("$FreeBSD$"); #include #include -static int iodev_pio_read(struct iodev_pio_req *req); -static int iodev_pio_write(struct iodev_pio_req *req); - static int iodev_efivar_getvar(struct iodev_efivar_req *req); static int iodev_efivar_nextname(struct iodev_efivar_req *req); static int iodev_efivar_setvar(struct iodev_efivar_req *req); /* ARGSUSED */ int -ioopen(struct cdev *dev __unused, int flags __unused, int fmt __unused, - struct thread *td) +iodev_open(struct thread *td __unused) { - int error; - - error = priv_check(td, PRIV_IO); - if (error == 0) - error = securelevel_gt(td->td_ucred, 0); - return (error); + return (0); } /* ARGSUSED */ int -ioclose(struct cdev *dev __unused, int flags __unused, int fmt __unused, - struct thread *td __unused) +iodev_close(struct thread *td __unused) { return (0); } -/* ARGSUSED */ int -ioioctl(struct cdev *dev __unused, u_long cmd, caddr_t data, - int fflag __unused, struct thread *td __unused) +iodev_ioctl(u_long cmd, caddr_t data) { struct iodev_efivar_req *efivar_req; - struct iodev_pio_req *pio_req; int error; - error = ENOIOCTL; switch (cmd) { - case IODEV_PIO: - pio_req = (struct iodev_pio_req *)data; - switch (pio_req->access) { - case IODEV_PIO_READ: - error = iodev_pio_read(pio_req); - break; - case IODEV_PIO_WRITE: - error = iodev_pio_write(pio_req); - break; - default: - error = EINVAL; - break; - } - break; case IODEV_EFIVAR: efivar_req = (struct iodev_efivar_req *)data; efivar_req->result = 0; /* So it's well-defined */ @@ -113,75 +85,11 @@ ioioctl(struct cdev *dev __unused, u_lon break; } break; - } - - return (error); -} - -static int -iodev_pio_read(struct iodev_pio_req *req) -{ - - switch (req->width) { - case 1: - req->val = bus_space_read_io_1(req->port); - break; - case 2: - if (req->port & 1) { - req->val = bus_space_read_io_1(req->port); - req->val |= bus_space_read_io_1(req->port + 1) << 8; - } else - req->val = bus_space_read_io_2(req->port); - break; - case 4: - if (req->port & 1) { - req->val = bus_space_read_io_1(req->port); - req->val |= bus_space_read_io_2(req->port + 1) << 8; - req->val |= bus_space_read_io_1(req->port + 3) << 24; - } else if (req->port & 2) { - req->val = bus_space_read_io_2(req->port); - req->val |= bus_space_read_io_2(req->port + 2) << 16; - } else - req->val = bus_space_read_io_4(req->port); - break; - default: - return (EINVAL); - } - - return (0); -} - -static int -iodev_pio_write(struct iodev_pio_req *req) -{ - - switch (req->width) { - case 1: - bus_space_write_io_1(req->port, req->val); - break; - case 2: - if (req->port & 1) { - bus_space_write_io_1(req->port, req->val); - bus_space_write_io_1(req->port + 1, req->val >> 8); - } else - bus_space_write_io_2(req->port, req->val); - break; - case 4: - if (req->port & 1) { - bus_space_write_io_1(req->port, req->val); - bus_space_write_io_2(req->port + 1, req->val >> 8); - bus_space_write_io_1(req->port + 3, req->val >> 24); - } else if (req->port & 2) { - bus_space_write_io_2(req->port, req->val); - bus_space_write_io_2(req->port + 2, req->val >> 16); - } else - bus_space_write_io_4(req->port, req->val); - break; default: - return (EINVAL); + error = ENOIOCTL; } - return (0); + return (error); } static int Modified: head/sys/ia64/include/iodev.h ============================================================================== --- head/sys/ia64/include/iodev.h Wed Apr 28 15:15:06 2010 (r207328) +++ head/sys/ia64/include/iodev.h Wed Apr 28 15:38:01 2010 (r207329) @@ -31,22 +31,16 @@ #include -struct iodev_pio_req { - u_int access; -#define IODEV_PIO_READ 0 -#define IODEV_PIO_WRITE 1 - u_int port; - u_int width; - u_int val; -}; - -#define IODEV_PIO _IOWR('I', 0, struct iodev_pio_req) +#ifdef _KERNEL +#include +#endif -struct iodev_efivar_req { - u_int access; #define IODEV_EFIVAR_GETVAR 0 #define IODEV_EFIVAR_NEXTNAME 1 #define IODEV_EFIVAR_SETVAR 2 + +struct iodev_efivar_req { + u_int access; u_int result; /* errno value */ size_t namesize; u_short *name; /* UCS-2 */ @@ -59,11 +53,16 @@ struct iodev_efivar_req { #define IODEV_EFIVAR _IOWR('I', 1, struct iodev_efivar_req) #ifdef _KERNEL +#define iodev_read_1 bus_space_read_io_1 +#define iodev_read_2 bus_space_read_io_2 +#define iodev_read_4 bus_space_read_io_4 +#define iodev_write_1 bus_space_write_io_1 +#define iodev_write_2 bus_space_write_io_2 +#define iodev_write_4 bus_space_write_io_4 + +int iodev_open(struct thread *td); +int iodev_close(struct thread *td); +int iodev_ioctl(u_long, caddr_t data); -d_open_t ioopen; -d_close_t ioclose; -d_ioctl_t ioioctl; - -#endif - +#endif /* _KERNEL */ #endif /* _MACHINE_IODEV_H_ */ _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"