The entire CLOS class and generic function hierarchy is effectively a (large, complicated) shared data structure; it's not generally practical for a thread to request exclusive access to all of CLOS, and the effects of volitional modification of the CLOS hierarchy (via class redefinition, CHANGE-CLASS, etc) in a multithreaded environment aren't always tractable.

Native threads exacerbate this problem (in that they increase the opportunities for concurrent modification and access.) The implementation should try to ensure that a thread's view of any subset of the CLOS hierarchy is consistent (to the extent that that's possible) and should try to ensure that incidental modifications of the hierarchy (cache updates, etc.) happen atomically; it's not generally possible for the implementation to guarantee that a thread's view of things is correct and current.

If you are loading code and defining classes in the most usual way, which is to say, via the compiler, using only a single thread, these issues are probably not going to affect you much.

If, however, you are making finicky changes to the class hierarchy while you're running multiple threads which manipulate objects related to each other, more care is required. Before doing such a thing, you should know what you're doing and already be aware of what precautions to take, without being told. That said, if you do it, you should seriously consider what your application's critical data is, and use locks for critical code sections.