Date: Fri, 2 May 1997 07:24:54 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: phk@dk.tfs.com (Poul-Henning Kamp) Cc: current@freebsd.org Subject: Re: vnode->v_usage Message-ID: <199705021124.HAA27754@hda.hda.com> In-Reply-To: <5321.862569821@critter> from Poul-Henning Kamp at "May 2, 97 12:43:41 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Ok, now I'm in doubt here... Which of these two places are the
> correct place to release the interlock, I've marked the candidates
> with XXX, I pressume the later, right ?
>
> void
> vtouch(vp)
> struct vnode *vp;
> {
> simple_lock(&vp->v_interlock);
> if (vp->v_usecount) {
> simple_unlock(&vp->v_interlock);
> return;
> }
> simple_unlock(&vp->v_interlock); /* XXX */
> simple_lock(&vnode_free_list_slock);
> TAILQ_REMOVE(&vnode_free_list, vp, v_freelist);
> TAILQ_INSERT_TAIL(&vnode_free_list, vp, v_freelist);
> simple_unlock(&vnode_free_list_slock);
> simple_unlock(&vp->v_interlock); /* XXX */
> }
>
The first unlock won't work since a second thread can come in and
decide to do the same move. Obviously you have a lock ordering issue
with the nested lock and you have to define the ordering.
Moving items between two lists should be atomic - it is common
and lends itself to clean implementation.
Aside: how about making the queues truly opaque while you're doing this?
Then you have a single place to enable locking hierarchy violation detection,
*CAS types of implementations, etc.
Peter
--
Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation
HD Associates, Inc. Voice: 508 433 6936
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705021124.HAA27754>