msleep() on recursivly locked mutexes

Robert Watson rwatson at FreeBSD.org
Sat Apr 28 09:57:34 UTC 2007


On Fri, 27 Apr 2007, Julian Elischer wrote:

> Basically you shouldn't have a recursed mutex FULL STOP. We have a couple of 
> instances in the kernel where we allow a mutex to recurse, but they had to 
> be hard fought, and the general rule is "Don't". If you are recursing on a 
> mutex you need to switch to some other method of doing things. e.g. 
> reference counts, turnstiles, whatever.. use the mutex to create these but 
> don't hold the mutex for long enough to need to recurse on it. A mutex 
> should generally lock, dash-in and work, unlock. We have some cases where 
> that is not true, but we are trying to get rid of them, not add more.

Most of these instances have to do with legacy code and data structures that 
involve high levels of code recursion and reentrance.  This is frequently an 
unreliable way to organize code anyway, and often involves other bugs that are 
less visible.  Over time, it's my hope that we can eliminate quite a few 
sources of remaining lock recursion, but there are some tricky cases involving 
repeated callbacks between layers that make that harder.  For example, in the 
socket/network pcb relationship, there's a lack of clarity on which side 
drives the overlapping state machines present in both sets of data structures. 
Over time, we're migrating towards a model in which the socket infrastructure 
is more of a "library" in service to network protocols that will drive the 
actual transitions, but in the mean time, lock recursion is required.

For any significantly rewritten or new code, I would expect that recursion 
would be avoided in almost all cases.

Robert N M Watson
Computer Laboratory
University of Cambridge


More information about the freebsd-hackers mailing list