httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject Re: More on early multiplexing.
Date Mon, 22 Mar 1999 13:34:05 GMT
On Sun, 21 Mar 1999, Dean Gaudet wrote:

> 
> 
> On Thu, 11 Mar 1999, Michael H. Voase wrote:
> 
> > blocked threads --> (server socket queue )  <---------------------
> > ^                               |                                 |
> > |                               V                                 |
> > |                        thread blocked on accept on socket X     |
> > |                               |                                 |
> > |                               V                                 |
> > |                        Unblocked by a request the thread -------
> > |                        enqueues server socket back onto queue
> > |                         wanders off with the client socket to
> > |                        service request
> > |                               |
> > |                               V
> > L_______________________ Thread completes the request
> >                          and rejoins queue for the next
> >                          server socket
> 
> I think the main problem with this is that it has two synchronization
> points -- you have to block on the queue on the way into and the way out
> of accept.

It has taken me a while to be able to express the concerns I have with
this algorithm, but I'll give it a try.

There are two cases that should be considered.  

1)  An OS with a thundering herd problem, in which case the queue would
have to go in shared memory, or we need another synchronization point.
With thundering herd, we want only one thread in the entire server
listening on the port.  By putting the queue in shared mem, we get that.
If we don't use shared mem, the other synchronization point is so that
each thread that gets a socket descriptor from it's process's queue has to
check that the port isn't being listened to by another process.

2)  An OS without a thundering herd problem, in which case, we want as
many threads as possible listening to a port.  This algorithm gives us
that ability, but each process would need it's own queue.

These two cases are at odds with each other, and I am having a hard time
resolving it.

The two synchronization points doesn't concern me.  The current fdqueue
implementation has two points of synchronization(1 in and 1 out), and it
is very fast.  The testing we have done seems to indicate that one process
handles all of the load until it is pegged, and then another process helps
out.

Ryan


_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	



Mime
View raw message