From owner-freebsd-arch@FreeBSD.ORG Mon Jun 2 17:14:30 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBF961065671 for ; Mon, 2 Jun 2008 17:14:29 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id A70168FC20 for ; Mon, 2 Jun 2008 17:14:29 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m52HEAFJ009079; Mon, 2 Jun 2008 13:14:10 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Mon, 02 Jun 2008 13:14:10 -0400 (EDT) Date: Mon, 2 Jun 2008 13:14:10 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <48439D06.6020408@elischer.org> Message-ID: References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> <4843808A.2060501@elischer.org> <48439D06.6020408@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , arch@freebsd.org Subject: Re: all mutexes -> read-write locks? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 17:14:30 -0000 On Mon, 2 Jun 2008, Julian Elischer wrote: > Daniel Eischen wrote: >> On Sun, 1 Jun 2008, Julian Elischer wrote: >> >>> Daniel Eischen wrote: >>>> On Sun, 1 Jun 2008, Ed Schouten wrote: >>>> >>>>> Hello Julian, >>>>> >>>>> * Julian Elischer wrote: >>>>>> it has been mentioned several times that through the evolution of the >>>>>> locking primitives it has come to be that mutexes and exclusively >>>>>> acquired reader-writer locks are almost the same in terms of overhead >>>>>> and that it might be a good move to define all mutexes to be >>>>>> actually just that. >>>>>> >>>>>> this would allow people to slowly go through the system, catching low >>>>>> hanging fruit by converting some of the mutex operations to reader >>>>>> acquisitions wherever a writer is not required, thus reducing general >>>>>> system contention. >>>>>> >>>>>> Is there any thought on this? Last I heard jhb had confirmed that it >>>>>> was feasible.. >>>>> >>>>> If this is going to be done, could we have mtx_* macro's pointing to the >>>>> proper read/write ops? I know, it's just names, but I think most novice >>>>> FreeBSD kernel hackers will almost instantaneously figure out what 'mtx' >>>>> stands for. >>>> >>>> Yes, mutex (mtx) is known very well. >>>> >>>> I don't think changing all mutex operations to rdlock operations >>>> is wise. They are two different animals, regardless of their >>>> implementation. Mutexes are very commonly used in device drivers, >>>> at least outside of FreeBSD. And just because our current >>>> implementation of them are the same as rwlocks doesn't mean that >>>> it will always be the same in the future. >>>> >>> >>> so let's imagine that mutexes dissappear... >>> :-) >> >> I'd rather not. What do you have against them? > > People use them without thinking about whether they need to be so > strict. > >> Their API is simple >> enough to use. If there is code that really wants to have multiple >> readers, by all means change it to use rwlocks. > > > yes but we have a lot of code that uses mutexes.. changing it would allow a > slow transition to using rw locks. > >> >> Take a look at Solaris kernel mutexes and see how you can init >> a mutex that is to be used in an interrupt handler. > > how does that help making more things use read locking? It doesn't, it shows one reason why mutexes can be different than read/write locks. I don't see how most low-level leaf drivers can make use of read/write locks. All they want to do is prevent simultaneous access to a device and setup I/O operations. By keeping the mutex and rwlock APIs separate regardless of their implementation, you allow the code to specify what kind of locking it wants. If you convert all mutexes to rwlocks you lose this information and it makes it harder to go back again. On the other hand, if you s/mtx_foo/rw_foo/, you still have to analyze the code to tell whether or not you can truly turn them into simultaneous read locks. So what is the harm in analyzing the code first, and then converting it to rwlocks IFF it can make use of it? -- DE