httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: some reasons why Apache 2.0 threaded is slower than prefork
Date Thu, 01 Mar 2001 21:44:16 GMT
> Cliff Woolley wrote:
> >
> > It's the "lock-free operations" part that I've been stumbling over
> > so far.
> OpenVMS on the VAX dealt with this by using the low bit of the
> pointer as a lock.  Blocks were always 64-bit aligned, so it
> was free.  They used interlocked instructions that were guaranteed
> atomic:  BBSSI (branch on bit set and set, interlocked) and BBCCI.
> I do not know how we could use that here, but it was simple and
> elegant.. thread, process, and SMP safe.
> --

Perhaps I should change the subject line, but I was playing with the time
optimization on Windows earlier in the week.  Created apr_mpm_time_now() which
returned apr_time_t with one second resolution. The winnt MPM had a timer
thread the poped once per second and set ap_mpm_time which ap_mpm_time_now()
fetched.  It occured to me then that any operations on 64 bit values
(apr_time_t) were almost certainly not thread safe :-( so I put the apr_lock
on it.  BTW, the critical section of apr_lock() is very efficient if there is
little lock contention.  Bottom line... The Windows GetSystemTime function is
very efficient (which agrees with my experience writing the AFPA kernel
webserver). I could detect NO difference between calling apr_time_now() and
apr_mpm_time_now() on Windows. The extra overhead of calling apr_time_now() on
each request is insignificant compared to where CPU cycles are being eaten


View raw message