Re: rwlocks, correctness over speed.
- From: Robert Watson <rwatson@xxxxxxxxxxx>
- Date: Sat, 24 Nov 2007 10:34:12 +0000 (GMT)
On Sat, 24 Nov 2007, Attilio Rao wrote:
2007/11/24, Robert Watson <rwatson@xxxxxxxxxxx>:
While I'm no great fan of recursion, the reality is that many of our kernel subsystems are not yet ready to disallow recursion on locks. Take a look at the cases where we explicitly enable recursive acquisition for mutexes--in practice, most network stack mutexes are recursive due to the recursive calling in the network stack. While someday I'd like to think we'll be able to eliminate some of that, but it won't be soon since it requires significant reworking of very complicated code. The current model in which recursion is explicitly enabled only where still required seems to work pretty well for the existing code, although it's hard to say yet in the code I've looked at whether read recursion would be required--the situations I have in mind would require purely write recursion. There's one case in the UNIX domain socket code where we do a locked test and conditional lock/unlock with an rwlock for exclusive locking because recursion isn't currently supported, and that's not a usage I'd like to encourage more of.
Oh, I just didn't notice this -- rwlock are only present in 7.0 and in 7.0 they support recursion in exclusive mode, so I'm not sure what do you mean with 'recursion isn't currently supported'.
I must have missed recursion arriving then -- I'll modify uipc_usrreq.c to set the recursion flag on the rwlock in UNIX domain sockets rather than doing the nasty hack that was previously required. At the time, the hack was added because it seemed recursion was not going to be added to rwlocks, but sonewconn() behavior for listen sockets really ended up requiring it.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: rwlocks, correctness over speed.
- From: Attilio Rao
- Re: rwlocks, correctness over speed.
- References:
- rwlocks, correctness over speed.
- From: Alfred Perlstein
- Re: rwlocks, correctness over speed.
- From: Max Laier
- Re: rwlocks, correctness over speed.
- From: Attilio Rao
- Re: rwlocks, correctness over speed.
- From: Max Laier
- Re: rwlocks, correctness over speed.
- From: Alfred Perlstein
- Re: rwlocks, correctness over speed.
- From: Stephan Uphoff
- Re: rwlocks, correctness over speed.
- From: Alfred Perlstein
- Re: rwlocks, correctness over speed.
- From: Stephan Uphoff
- Re: rwlocks, correctness over speed.
- From: Robert Watson
- Re: rwlocks, correctness over speed.
- From: Attilio Rao
- rwlocks, correctness over speed.
- Prev by Date: [FYI] transferlockers() function removed -- lockmgr KPI changed
- Next by Date: Re: rwlocks, correctness over speed.
- Previous by thread: Re: rwlocks, correctness over speed.
- Next by thread: Re: rwlocks, correctness over speed.
- Index(es):
Relevant Pages
|
|