Thread safety guarantees

Thread safety guarantees 線程安全性保證

Intrusive containers have thread safety guarantees similar to STL containers.
介入式容器具有與STL容器相似的線程安全性保證。

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.
其它函數，如使用安全鉤子的 is_linked() 成員函數檢查某個對象是否已被插入到容器中，形成了沒有容器引用的讀訪問，因此其它線程不能對該容器進行寫訪問(直接或間接)。

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.
因為同一個對象可以同時被使用不同的鉤子插入到多個容器中，所以 Boost.Intrusive 的線程安全性既與容器有關，也與由用戶手工管理生存期的對象有關。

As we can see, the analysis of the thread-safety of a program using Boost.Intrusive is harder than with non-intrusive containers.
如我們所見，一個使用 Boost.Intrusive 的程序的線程安全性分析要比使用非介入式容器困難。

To analyze the thread safety, consider the following points:
要分析線程安全性，考慮以下方面：

The auto-unlink hook's destructor and unlink() functions modify the container indirectly.
自斷鉤子的析構函數和 unlink() 函數會間接修改容器。
The safe mode and auto-unlink hooks' is_linked() functions are a read access to the container.
安全模式鉤子和自斷鉤子的 is_linked() 函數是對容器的讀訪問。
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.
向一個會被其它線程修改的容器插入對象是沒有線程安全性保證的，雖然在多數平台上，它是無鎖定線程安全的。