[RFC] sysctl locking
Don Lewis
truckman at FreeBSD.org
Mon Oct 11 12:30:32 PDT 2004
On 10 Oct, Suleiman Souhlal wrote:
> Hello,
>
> In the past few days, I have managed to remove Giant from sysctl. The
> patch is at
> http://people.freebsd.org/~ssouhlal/testing/sysctl-locking.diff
> This is the first time I ever do something like this, so I wouldn't be
> surprised if I am doing something wrong.
> Any suggestions/comments?
>
> green@ also pointed out that I might need to use memory barriers, or
> some other synchronization primitive, when setting oid_owner to NULL in
> sysctl_oid_disown, but I am unsure on how to do that..
>
> Thanks in advance for your help.
There seems to be a lot of locking/unlocking overhead in the oid lookup
and oid tree manipulation code. Doing the traversals at each level of
the tree without holding a lock for the entire time makes me nervous,
though I can't point to any specific problem. It might be better to
just hold a single lock across then entire lookup, insertion, or
deletion operation.
What happens if:
thread A owns an oid
thread B, which wants to delete the oid, goes to sleep to wait
for the oid
thread C wants the oid and goes to sleep
thread A releases the oid and wakes up thread B
thread B deletes the oid
thread C does ???
I don't think that you can arbitrarily remove
mtx_assert(&Giant, MA_OWNED)
from the handlers. Some of the handlers probably need Giant for correct
operation. It's probably possible to change these into
mtx_lock()/mtx_unlock() pairs.
More information about the freebsd-arch
mailing list