Date: Fri, 31 Aug 2001 10:55:26 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Mike Silbersack <silby@silby.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, <cvs-all@FreeBSD.ORG>, <cvs-committers@FreeBSD.ORG> Subject: Re: RE: cvs commit: src/sys/kern init_sysent.c sysv_msg.c sysv_sem.c Message-ID: <200108311755.f7VHtQl66146@earth.backplane.com> References: <Pine.BSF.4.30.0108302309010.75391-100000@niwun.pair.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Also, just for clarification, Giant can be grabbed recursively, correct?
:Our "SMP kernel synchronization rules" pages seems to imply so, but isn't
:too clear.
Yes, you can grab Giant recursively, but it isn't good to make a
habit of it. The best way to view Giant grabbing requirements is
to base your action on whether the procedure has been marked MPSAFE
or not. A procedure marked MPSAFE may be entered with or without Giant
held and so cannot assume that Giant will be held. A procedure not
marked MPSAFE will only be entered with Giant held.
I'm slowly documenting procedures - for example as I do the Giant
pushdown.
:(http://people.freebsd.org/~jasone/smp/smp_synch_rules.html, for
:reference.)
:
:Also, on that page it states:
:
:Do not tsleep()/msleep()/cv_wait() while holding a mutex other than Giant.
:
:Is this still true? With this restriction, threading sounds like it could
:be very tough. Might it be possible to double-check that page (it is
:almost a year old now) and add information which could be useful to others
:pushing down locks?
You cannot block while holding mutexes (other then Giant, because
the scheduler treats Giant as a special case and saves/restores it).
Generally the idea with mutexes is that they are *NOT* long term locks..
they are very different from lockmgr() locks. The idea with a mutex is
that you grab it for short periods only. For example, getppid() would
grab the current process and parent process's mutexes in order to
retrieve the parent's pid, then release them before returning.
Another example: vget() will grab the vp->v_interlock mutex in order
to manipulate vp->v_usecount, then release it and return the ref'd vp.
You can then use the vp (without holding the mutex). Of course there
are other issues too... for a vnode you generally obtain a lockmgr()
lock on it (VOP_LOCK()). lockmgr() internally uses a mutex to
manipulate the structure itself.
Typically when you need a long term handle on a structure, such as a
vnode, the mutex is only used to bump the ref count or otherwise
mark the structure as being in use, to prevent it from being ripped out
from under you, then the mutex is released and you now have a ref'd
handle on the structure that remains valid. The sx_*() locks
accomplish this in many respects, though they aren't perfect.
:Right now I'm thinking of protecting arc4random (it's not important, but
:I've been in it recently, and it's a very simple piece of code - one entry
:point.) However, just thinking about it I've already come up with a few
:questions:
:
:1. Do I need to grab Giant before calling down to the time functions?
:2. Do I need to grab Giant before calling into the random device? (I
:suspect not, since Mark wrote it recently.)
:
:I think that if a mini-faq on such things could be written, many people
:could start protecting things from the bottom up. In some cases, (like
:arc4random's), protecting it with a mutex won't be important for a while
:(until the tcp stack is threaded.) However, since threading things from
:the bottom up should be relatively easy, it might be worthwhile for us smp
:newbies to start with it while the more experienced do the heavy lifting
:from the top down.
:
:Thanks,
:
:Mike "Silby" Silbersack
Giant must be already held when calling any function not marked
MPSAFE. Functions marked MPSAFE may be called without Giant held
and thus must obtain Giant themselves if they call into functions
not marked MPSAFE.
The time functions are only half-MPSAFE. They aren't 100% MPSAFE
but they are close. That's something I intend to review.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108311755.f7VHtQl66146>