Re: all mutexes -> read-write locks?

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 <julian@xxxxxxxxxxxx> 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
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: [RFC] locking.9
    ... Sleep Mutexes ... Shared-Exclusive locks ... deschedules the thread while you are holding a SPIN mutex. ... .Ss Sleep Mutexes ...
    (freebsd-current)
  • [RFC] locking.9
    ... Sleep Mutexes ... Shared-Exclusive locks ... deschedules the thread while you are holding a SPIN mutex. ... .Ss Sleep Mutexes ...
    (freebsd-current)
  • Re: locking N mutexes simultaneously
    ... I need to map N mutexes to a sorted array of M mutexes ... acquire locks A B C D E while T2 tries for C E F, ... Lockers of the multimethod simultaneously otherwise I would create ... OBJ queue1 = new; ...
    (comp.programming.threads)
  • Re: Progress on scaling of FreeBSD on 8 CPU systems
    ... If moving away from sleepable mutexes introduces more ... Why don't the sleepable locking primitives perform better? ... My intention is to both get the sx locks changes into the tree so that sx ... John Baldwin ...
    (freebsd-current)
  • Re: all mutexes -> read-write locks?
    ... On Sun, 1 Jun 2008, Julian Elischer wrote: ... locking primitives it has come to be that mutexes and exclusively ... acquired reader-writer locks are almost the same in terms of overhead ... I don't think changing all mutex operations to rdlock operations ...
    (freebsd-arch)