MySQL faces many of the same complications as other programs that depend on threads.
When writing code that can be concurrently executed by several threads, functions from external libraries must be called with extra care. There is always a chance that the called code uses a global variable, writes to a shared file descriptor, or uses some other shared resource without ensuring mutual exclusion. If this is the case, we must protect the call by a mutex.
While exercising caution, MySQL must also avoid unnecessary
protection, or it will experience a decrease in performance. For
example, it is reasonable to expect
) to be thread-safe. Other potentially non-thread-safe
functions such as
often have thread-safe counterparts. The MySQL build configuration
scripts test whether these are available and use them whenever
possible. If the appropriate thread-safe counterpart is not detected,
the protective mutex is enabled as the last resort.
Overall, MySQL saves itself a lot of thread-safety worries by implementing many standard C library equivalents in the portability wrapper in mysys and in the string library under strings. Even when C library calls are made eventually, they happen through a wrapper in most cases. If a call on some system unexpectedly turns out to lack thread safety, the problem can be easily fixed by adding a protective mutex to the wrapper.
In a threaded server, several ...