On Friday, June 27, 2003, at 11:08 AM, Ken Ashcraft wrote:
Have race conditions and deadlock been a problem in the past? How likely is it that there are race condition and deadlock bugs hiding in the current source?
Race Conditions and Deadlocks are an issue both in the server and in modules. It's still possible that some exist in the server, but if we've done our job the big ones are gone.
Who are the developers who could answer my "is this a race condition" questions?
Anyone on this list (or on the [EMAIL PROTECTED] list). If you think you've found a race condition, please just post it to the appropriate list so that we can all discuss it. Any help you can provide would be appreciated.
Is there any documentation about locks in the server? Where they are used? How they are used? What do they protect?
They are implemented in APR. There are different types, depending on
what you want to protect and how you want to protect them. Take a
look at the locks/ subdirectory (srclib/apr/locks in the httpd tarball)
and in the srclib/apr/include/apr_{thread,process,global}_{mutex,rwlock,cond}.h
header files for the best documentation. (I gave a talk on this at
ApacheCon last year, but I haven't put up the materials yet. One of
these days I'll get around to it though...)
What files should I be looking at? Which use locks? Which contain the locking functions?
Many files in the httpd source tree call the various APR locking functions.
Just run grep over the whole tree.
Are there any absolute rules about locks (i.e. all global variables must
be protected by locks, orderings of lock acquisition)?
In general there aren't rules like that. We try to architect the system
in such a way to avoid locks at all (for example, we have a shared memory
scoreboard that contains the status of each child process, but because
of the way that shmem segment is accessed we don't need locks.) The times
when they are necessary are when data will be lost or corrupted if some
form of mutual exclusion weren't used.
-aaron
