By default, code compiled with code coverage uses non-atomic counters, which means that if the code runs in multiple threads it will occasionally drop a count. As the count is mostly used as heuristics this is usually not a problem (it will never drop all the counts, so you will not get 0 counts when there should be more than 0).
To record an exact count you can compile with atomic-p t (see generate-code-coverage and with-code-coverage-generation). Atomic incrementing may make the program run much more slowly, which is the reason that it is not the default behavior.
The code-coverage-data manipulation functions are thread-safe, and will not corrupt data or cause errors when running in parallel. However they are not atomic, so modifying the same structure in parallel will create inconsistent data. Reading the internal data while code with counters is executing may also generate an inconsistent data.
LispWorks User Guide and Reference Manual - 13 Feb 2015