From owner-freebsd-arch Tue May 30 10:16: 8 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 82F2037BC90 for ; Tue, 30 May 2000 10:16:03 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@localhost [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id LAA27213; Tue, 30 May 2000 11:15:54 -0600 (MDT) Message-Id: <200005301715.LAA27213@berserker.bsdi.com> To: Luoqi Chen Cc: arch@freebsd.org Subject: Re: Preemptive kernel on older X86 hardware From: Chuck Paterson Date: Tue, 30 May 2000 11:15:54 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A spin lock can only degenerates to a nop when it is known that it is held only by top half threads. It is true that there is no reason for spin and non-spin mutexs to share any of the implementation. In the case of BSD/OS no code is shared. I try not to use the term sleep when describing a mutex because this leads people to believe that the process ends up on a sleep(9) queue. Chuck ----- Begin Included Message ----- Date: Tue, 30 May 2000 13:02:22 -0400 From: Luoqi Chen To: cp@bsdi.com Subject: Re: Preemptive kernel on older X86 hardware cc: arch@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 ----- End Included Message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message