|
Boost Users : |
From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2005-04-13 01:58:01
Manges, Ross G <Ross.G.Manges <at> boeing.com> writes:
>
> 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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net