From owner-freebsd-smp Mon Jun 26 12:26:58 2000 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B242237B942 for ; Mon, 26 Jun 2000 12:26:53 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA29301; Mon, 26 Jun 2000 12:26:50 -0700 (PDT) (envelope-from dillon) Date: Mon, 26 Jun 2000 12:26:50 -0700 (PDT) From: Matthew Dillon Message-Id: <200006261926.MAA29301@apollo.backplane.com> To: Luoqi Chen Cc: jasone@canonware.com, smp@FreeBSD.ORG Subject: Re: SMP meeting summary References: <200006261646.e5QGkUS06290@lor.watermarkgroup.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> Compared with the use of tsleep(), mutexes have a number of :> advantages: :> :> - Each mutex has its own wait (sleep) queue. When a process releases :> a mutex, it automatically schedules the next process waiting on the :> queue. This is more efficient than searching a possibly very long, :> linear sleep queue. It also avoids the flooding when multiple :> processes get scheduled, and most of them have to go back to sleep :> again. :> :What about processes of different priorities blocking for the same mutex? :Would you do a linear search on the queue? or have the queue sorted by :priority? or a FIFO queue is good enough? : :-lq I've found the a sorted queue is best for this sort of thing. It is possible to do a low-overhead sorted queue by having the insertion code scan from the beginning forward AND the end backwards until it finds the insertion point. Usually it finds the insertion point in only one or two iterations. The wakeup code then simply pops the first proc from the queue and wakes it up. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message