Re: [Boost-users] [multi_index] thread safety

Conway Allen ha escrito:
Regarding thread safety, if threads are concurrently reading, inserting, and erasing entries in a multi-index container do you have to lockguard all of these operations or can you get away with just lockguarding the inserts and the deletes?
You have to lockguard every access to the container; note this also includes, for instance, container traversal with iterators, i.e. iterator displacement. Strictly speaking, iterator dereference should also be lockguarded, although I can say unofficially that unguarded dereference is OK. The kind of thread-safety provided by B.MI (and by most STL implementations) is described at SGI docs: http://www.sgi.com/tech/stl/thread_safety.html
Thanks, Allen.
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

hello Joaquin
You have to lockguard every access to the container; note this also includes, for instance, container traversal with iterators, i.e. iterator displacement. Strictly speaking, iterator dereference should also be lockguarded, although I can say unofficially that unguarded dereference is OK.
can you explain a litle more? as I konw from STL, multiple readers is ok. reading and inserting a new object does't invalidate iterators(for pointer-based conteiners offcourse,list, map etc...) a concurrent read and insert in multi_index are not (safely)possible? I mean there might be an iterator invalidation? offcourse there is a chance for a 'dirty-read' but this for the domain of the aplication if it is a problem and not for multi_index. thanks.
participants (2)
-
george
-
Joaquín Mª López Muñoz