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

----- Mensaje original -----
De: george
hello Joaquin
Hello George,
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.
Correct.
reading and inserting a new object does't invalidate iterators(for pointer-based conteiners offcourse,list, map etc...)
Correct. This also holds for multi_index_containers.
a concurrent read and insert in multi_index are not (safely)possible? I mean there might be an iterator invalidation?
Concurrent reading and writing is not safe, but the issue has nothing to do with iterator invalidation. ...I think I've got a hunch about what you've got in mind. When I say that you've got to lockguard iterator displacement, what I mean is: consider a concurrent write operation and an iterator increment; this concurrency is not thread safe and undefined behavior results: a possible outcome is iterator invalidation, but you could also get an app crash, a corrupted data structure, an infinite loop or whatever. Tecnhically speaking, an invalid iterator is a perfectly legal state for an iterator to be in, which has nothing to do with undefined behavior resulting from violating thread safety guarantees. I'm not sure I made myself clear :) Insist on me if I didn't.
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.
I don't get what you mean here, would you care to elaborate? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (1)
-
JOAQUIN LOPEZ MU?Z