From owner-freebsd-hackers Wed Apr 23 10:00:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA10135 for hackers-outgoing; Wed, 23 Apr 1997 10:00:05 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA10092 for ; Wed, 23 Apr 1997 10:00:01 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA29097; Wed, 23 Apr 1997 09:56:06 -0700 From: Terry Lambert Message-Id: <199704231656.JAA29097@phaeton.artisoft.com> Subject: Re: Scheduling with libc_r... To: fenyo@email.enst.fr Date: Wed, 23 Apr 1997 09:56:06 -0700 (MST) Cc: freebsd-hackers@FreeBSD.org, jb@cimlogic.com.au In-Reply-To: <199704230117.DAA21364@nikopol.enst.fr> from "Alex Fenyo" at Apr 23, 97 03:17:55 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Suppose we have two threads. > > The first one performs a read system call on a file descriptor, and > LATER, the second one performs a read system call on the same file > descriptor too. > > Suppose that the priority of the first thread is lower than the > priority of the second thread. > > So, we have 2 waiting threads : the low priority thread called read > before the high priority thread. > > The problem is that when something will be able to be read, the low > priority thread will run first, before the high priority one. [ ... ] > It is important to note that the high priority thread must > return first from the system call, BUT moreover, it must have > read the data first (during the system call). It is done, > with the modification I suggest. But only because a side effect > is that the low priority thread returns EAGAIN. Is this a POSIX threading definition requirement? If not, then I don't agree with this interpretation. Read requests are queued, and should be serviced in queue order, not in caller priority order. This means that there is an ambiguity in the ordering when multiple requests are queued behind an additional request, but for the two requests you cite, it's correct. Consider that there is, topologically, no difference between a read request *queued* later than a previous request, and a read request *initiated* later than a previous request. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.