Matthew Dillon wrote:
The real culprit here is passing held mutexes to unrelated procedures
in the first place because those procedures might have to block, in
order so those procedures can release and reacquire the mutex.
That's just bad coding in my view. The unrelated procedure has no
clue as to what the mutex is or why it is being held and really has no
business messing with it.
[description of DFLY spinlocks removed for brevity]
If I were to offer advise it would be: Just stop trying to mix water
and hot wax. Stop holding mutexes across potentially blocking procedure
calls. Stop passing mutexes into unrelated bits of code in order for
them to be released and reacquired somewhere deep in that code. Just
doing that will probably solve all of the problems being reported.
Actually Matt, I don't think there is much argument here.. It has come to the
time
where locking needs a big broom, and I suspect that there will be such a broom
activated at BSDCan. There is some work going on (by john and others) to
'unify and sanitise' the locking. We'll see where it goes.
Or is that wax and hot water?
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
