You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Bloom <rb...@raleigh.ibm.com> on 1999/02/18 21:30:42 UTC
Accept mutex in hybrid server.
Just hit upon a stumbling block for the hybrid server. Instead of using
an LockFile, we need to use an LockDirectory (thanks for the idea Manoj).
The basic problem, is that each acceptor thread is responsible for
accepting on one socket and one socket only. The way the code is written,
if the thread gets the accept_mutex, it just falls through to the accept,
and blocks until it gets data. The obvious problem with this, is that if
one process is accepting on two ports, and the first acceptor gets the
mutex, the second port has nobody listening on it. That spells
starvation.
The way around this, is to use an array of mutex's, one per socket. The
problem comes up again with FDLOCKing and FCNTLing serialization. Both of
these use one file, which is configurable, for their accept mutex. One
file won't do in our scheme for the reasons mentioned above.
Does anybody have any strong objections to using a configurable
LockDirectory?
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.
Re: Accept mutex in hybrid server.
Posted by Valentin Bazavan <ba...@hpias.cup.hp.com>.
On Feb 22, 8:58am, Dean Gaudet wrote:
> Subject: Re: Accept mutex in hybrid server.
>
>
> On Fri, 19 Feb 1999, Valentin Bazavan wrote:
>
> > fcntl allows you to lock byte ranges in a file (even a 0-length file).
Thus,
> > you can have your array of mutexes by locking one byte in the lock file for
> > each socket. As a matter of fact, this approach should be taken also with
the
> > current fcntl based serialization. It would be more efficient, because
there
> > would be no need to open and close the lock file every time.
>
> I must be missing how this helps 1.x (I assume that's what you mean by
> "current"). We open the lock file once per server restart...
>
> Dean
>
>-- End of excerpt from Dean Gaudet
You are right. For some reason I was under the impression that the lock file
is opened/closed every time the mutex is turned on/off.
There might still be some benefit in using byte locking: only one file
descriptor is used, regardless of the number of processes.
Valentin Bazavan
Re: Accept mutex in hybrid server.
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 19 Feb 1999, Valentin Bazavan wrote:
> fcntl allows you to lock byte ranges in a file (even a 0-length file). Thus,
> you can have your array of mutexes by locking one byte in the lock file for
> each socket. As a matter of fact, this approach should be taken also with the
> current fcntl based serialization. It would be more efficient, because there
> would be no need to open and close the lock file every time.
I must be missing how this helps 1.x (I assume that's what you mean by
"current"). We open the lock file once per server restart...
Dean
Re: Accept mutex in hybrid server.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
Thanks for the tip. I'll look into implementing this this weekend. I
have the multiple accept mutex's working right now, and I am about to
commit, but hopefully this idea will improve our performance.
Thanks,
Ryan
On Fri, 19 Feb 1999, Valentin Bazavan wrote:
> On Feb 18, 3:30pm, Ryan Bloom wrote:
> > Subject: Accept mutex in hybrid server.
> .
> >
> > The way around this, is to use an array of mutex's, one per socket. The
> > problem comes up again with FDLOCKing and FCNTLing serialization. Both of
> > these use one file, which is configurable, for their accept mutex. One
> > file won't do in our scheme for the reasons mentioned above.
>
> fcntl allows you to lock byte ranges in a file (even a 0-length file). Thus,
> you can have your array of mutexes by locking one byte in the lock file for
> each socket. As a matter of fact, this approach should be taken also with the
> current fcntl based serialization. It would be more efficient, because there
> would be no need to open and close the lock file every time.
>
> Valentin Bazavan
>
> > 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.
> >
> >
> >-- End of excerpt from Ryan Bloom
>
>
>
_______________________________________________________________________
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.
Re: Accept mutex in hybrid server.
Posted by Valentin Bazavan <ba...@hpias.cup.hp.com>.
On Feb 18, 3:30pm, Ryan Bloom wrote:
> Subject: Accept mutex in hybrid server.
.
>
> The way around this, is to use an array of mutex's, one per socket. The
> problem comes up again with FDLOCKing and FCNTLing serialization. Both of
> these use one file, which is configurable, for their accept mutex. One
> file won't do in our scheme for the reasons mentioned above.
fcntl allows you to lock byte ranges in a file (even a 0-length file). Thus,
you can have your array of mutexes by locking one byte in the lock file for
each socket. As a matter of fact, this approach should be taken also with the
current fcntl based serialization. It would be more efficient, because there
would be no need to open and close the lock file every time.
Valentin Bazavan
> 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.
>
>
>-- End of excerpt from Ryan Bloom
Re: Accept mutex in hybrid server.
Posted by Dean Gaudet <dg...@arctic.org>.
The LockFile thing is just a prefix anyhow -- we append the pid or
something like that anyhow... I suggest just appending some magic number
to distinguish the different locks.
Dean
On Thu, 18 Feb 1999, Ryan Bloom wrote:
>
> Just hit upon a stumbling block for the hybrid server. Instead of using
> an LockFile, we need to use an LockDirectory (thanks for the idea Manoj).
> The basic problem, is that each acceptor thread is responsible for
> accepting on one socket and one socket only. The way the code is written,
> if the thread gets the accept_mutex, it just falls through to the accept,
> and blocks until it gets data. The obvious problem with this, is that if
> one process is accepting on two ports, and the first acceptor gets the
> mutex, the second port has nobody listening on it. That spells
> starvation.
>
> The way around this, is to use an array of mutex's, one per socket. The
> problem comes up again with FDLOCKing and FCNTLing serialization. Both of
> these use one file, which is configurable, for their accept mutex. One
> file won't do in our scheme for the reasons mentioned above.
>
> Does anybody have any strong objections to using a configurable
> LockDirectory?
>
> 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.
>
>
>