From owner-freebsd-hackers Thu Apr 24 15:28:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA05574 for hackers-outgoing; Thu, 24 Apr 1997 15:28:30 -0700 (PDT) Received: from werple.net.au (melb.werple.net.au [203.9.190.18]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA05552 for ; Thu, 24 Apr 1997 15:28:26 -0700 (PDT) Received: (qmail 29681 invoked by uid 5); 24 Apr 1997 22:28:21 -0000 Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id IAA01974; Fri, 25 Apr 1997 08:17:02 +1000 (EST) From: John Birrell Message-Id: <199704242217.IAA01974@freebsd1.cimlogic.com.au> Subject: Re: Scheduling with libc_r... To: fenyo@email.enst.fr Date: Fri, 25 Apr 1997 08:17:01 +1000 (EST) 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.4ME+ PL22 (25)] 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 Alex Fenyo wrote: [...] > 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. If a low priority thread performs a blocking read() and later a higher priority thread also performs a blocking read() on the same file descriptor, then scheduling will not solve the problem. This would need a fix to _thread_fd_lock() to check the priority of the thread that has the lock, and if lower, push that thread into the lock queue. But then there is the problem of the incremental priority that will eventually mean that the lower priority thread has a greater effective priority than the other thread, simply because it has been ready to run for too long. I have difficulty understanding what sort of application would have two threads of different priorities that can read from the same fd and then not work properly if the lower priority thread gets the data instead of the higher priority thread. This seems like a hypothetical situation. One thread reading on the same file descriptor that another writes on is a different issue, though. [...] Regards, -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org; jb@freebsd.org CIMlogic Pty Ltd, 119 Cecil Street, South Melbourne Vic 3205, Australia Tel +61 3 9690 6900 Fax +61 3 9690 6650 Mob +61 418 353 137