Multi-threading access to device drivers.

[Daniel Eischen]

On Sun, 7 Nov 2004, Poul-Henning Kamp wrote:

> In message <20041107003842.GB73306 at 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