Thread safety guarantees

Intrusive containers have thread safety guarantees similar to STL containers.

Several threads having read or write access to different instances is safe as long as inserted objects are different.
Concurrent read-only access to the same container is safe.

Some Intrusive hooks (auto-unlink hooks, for example) modify containers without having a reference to them: this is considered a write access to the container.

Other functions, like checking if an object is already inserted in a container using the is_linked() member of safe hooks, constitute read access on the container without having a reference to it, so no other thread should have write access (direct or indirect) to that container.

Since the same object can be inserted in several containers at the same time using different hooks, the thread safety of Boost.Intrusive is related to the containers and also to the object whose lifetime is manually managed by the user.

As we can see, the analysis of the thread-safety of a program using Boost.Intrusive is harder than with non-intrusive containers.

To analyze the thread safety, consider the following points:

The auto-unlink hook's destructor and unlink() functions modify the container indirectly.
The safe mode and auto-unlink hooks' is_linked() functions are a read access to the container.
Inserting an object in containers that will be modified by different threads has no thread safety guarantee, although in most platforms it will be thread-safe without locking.