Date: Fri, 25 Apr 1997 08:17:01 +1000 (EST) From: John Birrell <jb@cimlogic.com.au> To: fenyo@email.enst.fr Cc: freebsd-hackers@FreeBSD.org, jb@cimlogic.com.au Subject: Re: Scheduling with libc_r... Message-ID: <199704242217.IAA01974@freebsd1.cimlogic.com.au> In-Reply-To: <199704230117.DAA21364@nikopol.enst.fr> from Alex Fenyo at "Apr 23, 97 03:17:55 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704242217.IAA01974>