lkml.org 
[lkml]   [2000]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: kqueue microbenchmark results
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/

\
 
 \ /
  Last update: 2005-03-22 12:45    [W:0.061 / U:3.340 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site