Date: Mon, 26 Jun 2000 12:26:50 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Luoqi Chen <luoqi@watermarkgroup.com> Cc: jasone@canonware.com, smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <200006261926.MAA29301@apollo.backplane.com> References: <200006261646.e5QGkUS06290@lor.watermarkgroup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006261926.MAA29301>