Possible traversal and modifications of a safe container iterators list inside safe_mode::detach_equivalent_iterators function are not protected with locking like the following one in safe_iterator_base::detach function. #if defined(BOOST_HAS_THREADS) boost::detail::lightweight_mutex::scoped_lock lock(cont->mutex); #endif Unless some kind of synchronization is provided by callers of the safe_mode API, the list above can be traversed/modified and modified concurrently in BOOST_HAS_THREADS environment. It would be great if somebody can confirm or deny that there is the access synchronization problem. Regards, Anatoly
Anatoly Pinchuk <appinchuk <at> gmail.com> writes:
Possible traversal and modifications of a safe container iterators list inside safe_mode::detach_equivalent_iterators function are not protected with locking like the following one in safe_iterator_base::detach function [...]
Hi Anatoly, Yep, safe_mode::detach_equivalent_iterators is not mutex-protected, but this is not an error: this function is called only in the context of erase and update operations, where no concurrent access to the container is allowed. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquin M Lopez Munoz <joaquin <at> tid.es> writes:
Anatoly Pinchuk <appinchuk <at> gmail.com> writes:
Possible traversal and modifications of a safe container iterators list inside safe_mode::detach_equivalent_iterators function are not protected with locking like the following one in safe_iterator_base::detach function [...]
Hi Anatoly,
Yep, safe_mode::detach_equivalent_iterators is not mutex-protected, but this is not an error: this function is called only in the context of erase and update operations, where no concurrent access to the container is allowed.
Hi again, Maybe I answered too fast. Considering the following scenario: Thread A: iterator it1=it2; Thread B: c.erase(...); we have a race as iterator assigning meddles with the internal safe iterator list. I tend to consider the scnario above as legitimate, so maybe we have an issue here. Thanks for reporting. Let me study this a little further, I've created a ticket for it at: https://svn.boost.org/trac/boost/ticket/3462 Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Hi again,
Maybe I answered too fast. Considering the following scenario:
Thread A: iterator it1=it2; Thread B: c.erase(...);
we have a race as iterator assigning meddles with the internal safe iterator list. I tend to consider the scnario above as legitimate, so maybe we have an issue here. Thanks for reporting. Let me study this a little further, I've created a ticket for it at:
Hi Joaquin, Yes, the race seems to be real since there are list manipulations without locking the list first. Even if these manipulations are done in the context of exclusive container operation, like delete, it is possible that other thread is changing the same list as result of an iterator related operation, like iterator destruction. Thanks, Anatoly
Anatoly Pinchuk escribió:
Hi again,
Maybe I answered too fast. Considering the following scenario:
Thread A: iterator it1=it2; Thread B: c.erase(...);
we have a race as iterator assigning meddles with the internal safe iterator list. I tend to consider the scnario above as legitimate, so maybe we have an issue here. Thanks for reporting. Let me study this a little further, I've created a ticket for it at:
Hi Joaquin,
Yes, the race seems to be real since there are list manipulations without locking the list first. Even if these manipulations are done in the context of exclusive container operation, like delete, it is possible that other thread is changing the same list as result of an iterator related operation, like iterator destruction.
Hi, thanks again for reporting. The problem was indeed a bug and I was able to expose it through a testing program. Fixed in trunk, soon to be committed to the release branch: https://svn.boost.org/trac/boost/changeset/56354 Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Hi, thanks again for reporting. The problem was indeed a bug and I was able to expose it through a testing program. Fixed in trunk, soon to be committed to the release branch:
https://svn.boost.org/trac/boost/changeset/56354
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________
Hi Joaquín, Thank you for the prompt investigation and fix of the bug. I have one less problem to deal with :). Anatoly
participants (3)
-
Anatoly Pinchuk -
Joaquin M Lopez Munoz -
joaquin＠tid.es