From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 13:30:51 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67E8A16A4CE for ; Sun, 7 Nov 2004 13:30:51 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1429F43D31 for ; Sun, 7 Nov 2004 13:30:51 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iA7DUn26000306; Sun, 7 Nov 2004 08:30:49 -0500 (EST) Date: Sun, 7 Nov 2004 08:30:49 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Poul-Henning Kamp In-Reply-To: <18451.1099814158@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: arch@freebsd.org cc: John-Mark Gurney Subject: Re: Multi-threading access to device drivers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2004 13:30:51 -0000 On Sun, 7 Nov 2004, Poul-Henning Kamp wrote: > In message <20041107003842.GB73306@funkthat.com>, John-Mark Gurney writes: > >Poul-Henning Kamp wrote this message on Sun, Nov 07, 2004 at 00:39 +0100: > >> Assume a device driver which is not Giant-handicapped. > >> > >> Assume an I/O path which does not need Giant to get from > >> read(2) to the device driver. > >> > >> Assume a SMP machine. > >> > >> Assume a process with two threads on two CPUs, both > >> doing read(fd, buf, len) at the same time. > >> > >> Should we let both reads into the driver at the same time ? > >> > >> If so, which uio_offset do we hand them ? > > > >As was quoted POSIX, the update should be atomic.. so my reading of > >that is that you lock the fd, when you read the offset from the fd, > >you need to also update the offset with the number of bytes read, so > >that a racing read both doesn't drop any data, nor duplicate any data.. > > See, this is where the fine print has to be read. > > If the device is not addressable, this is only a locking problem, > something the driver should already be handling. > > If the device driver is addressable (ie: a disk), you would not > read it from two threads without explicitly giving an offset (ie. > using pread(2)). > > If you really want to read it sequentially using two (or more) > threads, then I think it is fair to ask that you do the locking > in userland. I guess I'd agree with the last part. If there is no locking in userland, then even if there is locking in the kernel, there is no guarantee that the first thread in is the first thread out and the first thread to be run (or resumed). Regardless, the kernel shouldn't return duplicated data nor skip over any data. It is possible for the program to be reading records where sequence doesn't matter but loss, duplication, or otherwise corruption of data does. -- Dan Eischen