From owner-freebsd-arch Tue May 30 10: 2:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 63E9D37BC90 for ; Tue, 30 May 2000 10:02:24 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.10.1/8.10.1) id e4UH2MX14070; Tue, 30 May 2000 13:02:22 -0400 (EDT) Date: Tue, 30 May 2000 13:02:22 -0400 (EDT) From: Luoqi Chen Message-Id: <200005301702.e4UH2MX14070@lor.watermarkgroup.com> To: cp@bsdi.com Subject: Re: Preemptive kernel on older X86 hardware Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The two types of mutex (spinning and sleeping) are quite different. A spinning mutex is owned by a cpu, and degenerates into a no-op when ncpu == 1; on the other hand, a sleeping mutex is owned by a thread and is nontrivial for UP preemptive kernels. IMHO, it is a good idea to have a separate implementation for each type, for example, we don't need to deal with priority inversion in the spinning case (the thread that holds the spinning mutex should not be preempted). -lq > On Thu, 25 May 2000, Chuck Paterson wrote: > > > } > > } Lets use subroutines during development at least, it will make > > } things easier. I don't think anyone can argue with that :-) > > } > > > > Almost.) I certainly think that the actually locking > > stuff can be in a function but we really want to wrap the > > function in a macro so we can put tracing in. Being able > > to look at a trace and see file and line numbers for mutex > > locks and unlocks is invaluable. > > Absolutely. If using functions, it might also be a good idea to wrap with > an inline which checks for M_SPIN or M_DEF and calls a different > implementation function for each. This might allow a slightly more > efficient implementation. > > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message