Re: Shared spinlocks
:Hi,
:
:Why don't we have shared spinlocks anymore?
:
:Thanks,
:-- vs
Sometimes excessive complexity leads to excessive confusion.
The shared spinlocks were a pretty horrible hack that I added
on an otherwise pristine mechanism. There were severe limitations
on recursive use. The only thing that used them that was actually
in the critical path was the file descriptor code and frankly I
don't think there is much of a point when the lock is only held
for a few instruction cycles anyway. If it comes down to it there
are faster ways to implement fast file descriptor lookups if we
decide we really need it.
If I reduce the spinlock code to just exclusive locks and get rid
of the extending naming I think people will have an easier time
using them properly. Right now our biggest problem is that the
spinlocks are not being used properly... they are not supposed to
be held across any complex kernel procedure call (like kfree),
or huge long chains of procedures (though we might not have a
choice when it comes to syscons).
Also our kern_mutex.c module has full read/write/chaining semantics
and provides a similar interface.
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)