Re: kqueue microbenchmark results

[Dan Kegel <dank@alumni.caltech.edu>]

Terry Lambert wrote:
> 
> > > Which is precisely why you need to know where in the chain of events this
> > > happened. Otherwise if I see
> > >         'read on fd 5'
> > >         'read on fd 5'
> > > How do I know which read is for which fd in the multithreaded case
> >
> > That can't happen, can it?  Let's say the following happens:
> >    close(5)
> >    accept() = 5
> >    call kevent() and rebind fd 5
> > The 'close(5)' would remove the old fd 5 events.  Therefore,
> > any fd 5 events you see returned from kevent are for the new fd 5.
> 
> Strictly speaking, it can happen in two cases:
> 
> 1)      single acceptor thread, multiple worker threads
> 2)      multiple anonymous "work to do" threads
> 
> In both these cases, the incoming requests from a client are
> given to any thread, rather than a particular thread.
> 
> In the first case, we can have (id:executer order:event):
> 
> 1:1:open 5
> 2:2:read 5
> 3:4:read 5
> 2:3:close 5
> 
> If thread 2 processes the close event before thread 3 processes
> the read event, then when thread 3 attempts procssing, it will
> fail.

You're not talking about kqueue() / kevent() here, are you?
With that interface, thread 2 would not see a close event;
instead, the other events for fd 5 would vanish from the queue.
If you were indeed talking about kqueue() / kevent(), please flesh
out the example a bit more, showing who calls kevent().

(A race that *can* happen is fd 5 could be closed by another
thread after a 'read 5' event is pulled from the event queue and
before it is processed, but that could happen with any
readiness notification API at all.)

- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/