:>:This is due to the sx worker locks not using MTX_NOWITNESS with the pool
:>:mutex
:>:changes. It's not a problem though.
:>:
:>:--
:>:
:>:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
:>
:> Would it make sense for me to add a new MTX flag that disables certain
:> non-applicable warnings?
:
:Err, that's what MTX_NOWITNESS sort of does. This one is a bit hard, as you
:need a way to tell witness to ignore the lock orders between the reader writer
:locks and the smaller locks used in implementing those locks. Using
:MTX_NOWITNESS on the sx worker locks worked great for this. If the sx locks
:had their own pool of MTX_NOWITNESS locks that would work fine. They could
:share this pool with the lockmgr worker locks as well. They shouldn't be used
:for anything else, however. This is why I wanted to allow for multiple pools.
:
:--
:
:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
I'm not against the concept of multiple pools, but I'm not really
for it either. The various mutexes are already far too complex
for their own good... look at SX locks, for example. The
struct sx is about 8 times as big as it needs to be to implement
reasonable functionality. I would scrap the upgrade and
downgrade API and I would scrap the condition variables
and go with a simple shared/exclusive counter.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
