Date: Sun, 07 Nov 2004 08:55:58 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: arch@freebsd.org Subject: Re: Multi-threading access to device drivers. Message-ID: <18451.1099814158@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 06 Nov 2004 16:38:42 PST." <20041107003842.GB73306@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18451.1099814158>