11.3. Concurrency issues

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.