Thread safety guarantees

Intrusive containers have similar same thread-safety guarantees than STL containers.

Several threads can have 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 objects is already inserted in a containers using the is_linked() member of safe hooks is a read-access to the container without having a reference to them, 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 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, take in care the following points:

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

Boost C++ Libraries

Thread safety guarantees