I'm running into an invariant test failure (I have BOOST_MULTI_INDEX_INVARIANT_ASSERT defined). Specifically, the trace that follows indicates that the assert fails during a MultiIndexSet "insert" operation. Additionally, I only see this happen when I'm running multi-threaded tests. I have the call to insert() wrapped by a mutex to prevent multiple threads from calling it at the same time. Has anyone else had trouble like this? Searching the users list for multi_index and invariant doesn't turn up much. I'm using the boost library version 1_32 on RHEL3. Thanks for any help.
Manges, Ross G
I'm running into an invariant test failure (I have BOOST_MULTI_INDEX_INVARIANT_ASSERT defined).
Specifically, the trace that follows indicates that the assert fails during a MultiIndexSet "insert" operation. Additionally, I only see this happen when I'm running multi-threaded tests. I have the call to insert() wrapped by a mutex to prevent multiple threads from calling it at the same time.
So, once you have mutex-guarded your code, the problem does not show? Please confirm.
Has anyone else had trouble like this? Searching the users list for multi_index and invariant doesn't turn up much. I'm using the boost library version 1_32 on RHEL3. Thanks for any help.
Boost.MultiIndex does not have any multithreading protection for simultaneous writings to the same container. With respect to multithreading, only the following guarantees hold: 1. Simultaneous ops to different containers are safe. 2. Simultaneous read ops to the same container are safe. Other than that, you'll have to guard your code with mutexes like you say you're doing now. Please note that this is the situation also with STL containers, at least in many implementations. Some stdlibs provide threadsafe alternatives that internally serialize access to the containers, but this is IMHO a very bad design decision: Most often than not, synchronization is properly made with respect to operations more complex than a single access to a container (think of a bank account transaction, for instance), so in the end access-level synchronization gives the wrong level of atomicity and constitutes a flagrant case of premature pessimization. Your opinion may differ, of course. Hope this helps. Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (2)
-
Joaquin M Lopez Munoz
-
Manges, Ross G