A possible race conditions can't happen between the virtualhosts. They can happen between the apache child processes (threads).
If multiple apache virtualhosts would log into the same file, using the same apache child process/thread, it would not mean a real trouble source, because a single process/thread serves only a single request at once.
A race problem can happen if multiple requests, thus multiple child processes/threads are logging into the same file concurrently. However, it can happen by the same virtualhost - and thus, by the same log file - if it serves concurrently multiple requests, and thus it might append the logfile also concurrently. This can happen even with a single logfile in a single virtual host.
Concurrency in Apache logging
In the source code of the common log directives, it is clearly visible, that logging happens with the
apr_file_write_full() API call from an internal buffer into the log file (see
flush_log() around line 1135).
A deeper inspection of the source shows, in the case if a single log event would result multiple lines, then concurrent writes could mix the lines, but not the content. However, in ordinary CustomLog directives, it is impossible.
Furthermore, checking the low-level behavior, we can also find that the apr library - the internal cross-platform API of the apache - uses the
apr_file_write(), which call - already atomic -
write() calls. These happens in block sizes, these blocks are probably the same as the system page sizes, what is 4096. Ordinary CustomLog directives practically never become so long.
If you somehow trick the Apache logging to create extremely crappy log entries, with lines longer than the page size (4096), I would not close out some possibility of crapped log. However, I am nearly sure that apache does something against it.