Date: Mon, 2 Jun 2008 10:19:46 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Daniel Eischen <eischen@vigrid.com> Cc: Ed Schouten <ed@80386.nl>, Julian Elischer <julian@elischer.org>, arch@freebsd.org Subject: Re: all mutexes -> read-write locks? Message-ID: <20080602171946.GJ48790@elvis.mu.org> In-Reply-To: <Pine.GSO.4.64.0806021300290.3976@sea.ntplx.net> References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> <Pine.GSO.4.64.0806020048510.1533@sea.ntplx.net> <4843808A.2060501@elischer.org> <Pine.GSO.4.64.0806020111340.1533@sea.ntplx.net> <48439D06.6020408@elischer.org> <Pine.GSO.4.64.0806021300290.3976@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
* Daniel Eischen <eischen@vigrid.com> [080602 10:14] wrote: > On Mon, 2 Jun 2008, Julian Elischer wrote: > > > >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? I agree with Daniel here. I also think the following points are relevant: 1) we don't need to rototil the code to s/mtx/rw/ right now. 2) rw locks may not be as effecient as mtx later on and there's no point in doing it right now. -- - Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080602171946.GJ48790>