tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Fileassoc locking
On Sat, Dec 26, 2009 at 01:50:55AM +0100, Adam Hamsik wrote:
>
> RW locks have some performance problems, and they should not be used
> until it's needed.
> I think that same think can be accomplished by using reference
> counters and mutexes/cv variables.
A RW lock has to do a mutex acquire/release when it is acquired and
released - so has twice as many locked bus cycles as a simple mutex.
As such it isn't that different from a locked reference count (after
all that is what has to happen to allow multiple readers of a RW lock).
Unless you actually want a RW lock, it probably isn't what you should
be using. Separate mutex and CV give you a lot more flexibility [1].
> Rw locks has very bad effect on CPU caches and can slow things
> down on a bigger SMP systems.
Actually RW locks are probably only ever worthwhile on big SMP systems!
RW locks allow additional concurrency! The chance of mutex contention
is roughly the % of time spent with the mutex held multiplied by the
number of cpus (assuming you don't actually sleep with the mutex held).
So unless the mutex is held for a long time and there are a lot of cpus
then contention is relatively unlikely (particularly with a real workload).
It is much like other places where having too fine grained locks slows
things down (as well as making the locking hierarchy too complex).
David
[1] Hampered when some C++ lock library derives 'condvar' from 'mutex'
thus stopping you using the same mutex for many CV.
--
David Laight: david%l8s.co.uk@localhost
Home |
Main Index |
Thread Index |
Old Index