From owner-freebsd-arch  Sat Sep 23 15:43:18 2000
Delivered-To: freebsd-arch@freebsd.org
Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1])
	by hub.freebsd.org (Postfix) with ESMTP
	id 834A237B422; Sat, 23 Sep 2000 15:43:14 -0700 (PDT)
Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1])
	by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id QAA19490;
	Sat, 23 Sep 2000 16:43:07 -0600 (MDT)
Message-Id: <200009232243.QAA19490@berserker.bsdi.com>
To: Bosko Milekic <bmilekic@technokratis.com>
Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org
Subject: Re: mbuf system and SMPng 
In-reply-to: Your message of "Sat, 23 Sep 2000 14:46:44 EDT."
             <Pine.BSF.4.21.0009231425080.7679-100000@jehovah.technokratis.com> 
From: Chuck Paterson <cp@bsdi.com>
Date: Sat, 23 Sep 2000 16:43:07 -0600
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Date: Sat, 23 Sep 2000 14:46:44 -0400
From:  Bosko Milekic <bmilekic@technokratis.com>
To:  Chuck Paterson <cp@bsdi.com>
Subject:  Re: mbuf system and SMPng
cc:  freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG

Bosko Milekic wrote on: Sat, 23 Sep 2000 14:46:44 EDT

}	Indeed, the lock being released before the asleep() being called in
}  m_mballoc_wait() is somewhat of a race. I was planning to get rid of the
}  asleep/await combo anyway (noted in my journal). In fact, MGET() can be
}  called even with the mutex held, it will just result in recursive
}  grabbing of the mutex, but it's better to just re-arrange the macro with
}  a lower-level one, as you say (I noticed BSD/OS does something like
}  this).
}

	One thing to remember about the recursive stuff is that
passing a recursively held mutex to msleep() will not get the
mutex released, it will only release it one time. This means
that you likely won't be able to get a wakeup.  This could
be changed, but ->>in general<<- something has gone very wrong
if the mutex passed in to msleep() is recursively held. There
is likely a layer of code that is expecting that its data is protected,
and is not expecting some other process to be able to get at it.

Chuck



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message