Date: Sun, 01 Jun 2008 22:09:30 -0700 From: Julian Elischer <julian@elischer.org> To: Daniel Eischen <eischen@vigrid.com> Cc: Ed Schouten <ed@80386.nl>, arch@freebsd.org Subject: Re: all mutexes -> read-write locks? Message-ID: <4843808A.2060501@elischer.org> In-Reply-To: <Pine.GSO.4.64.0806020048510.1533@sea.ntplx.net> References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> <Pine.GSO.4.64.0806020048510.1533@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > On Sun, 1 Jun 2008, Ed Schouten wrote: > >> Hello Julian, >> >> * Julian Elischer <julian@elischer.org> 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... :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4843808A.2060501>