Hi Here is a proposal to fix this data race issue. I finally generalized bitset approach to fix it by inheriting from the normal iterator first and then the _Safe_iterator_base type. None of the libstdc++ iterator types are final so it is fine. Surprisingly, despite inheritance being private gcc got confused between _Safe_iterator_base _M_next and forward_list _M_next so I need to adapt some code to make usage of _Safe_iterator_base _M_next explicit. I also consider any operator where normal iterator is being modified while the safe iterator is linked to the list of iterators. This is necessary to make sure that thread sanatizer won't consider a race condition. I didn't touch to bitset::reference because list references are only access on bitset destruction which is clearly not an operation allowed to do while playing with references in another thread. Do you see any way to check for this problem in the testsuite ? Is there a thread sanitizer we could use ? 2014-09-10 François Dumont PR libstdc++/62313 * include/debug/safe_base.h (_Safe_iterator_base(const _Safe_iterator_base&)): Delete declaration. (_Safe_iterator_base& operator=(const _Safe_iterator_base&)): Likewise. * include/debug/safe_iterator.h (_Safe_iterator<>): Move normal iterator before _Safe_iterator_base in memory. Lock before modifying the iterator in numerous places. * include/debug/safe_local_iterator.h (_Safe_local_iterator_base(const _Safe_local_iterator_base&)): Delete declaration. (_Safe_local_iterator_base& operator=(const _Safe_local_iterator_base&)): Likewise. * include/debug/safe_unordered_base.h (_Safe_local_iterator<>): Move normal iterator before _Safe_iterator_base in memory. Lock before modifying the iterator in numerous places. * include/debug/forward_list (_Safe_forward_list<>::_M_swap_aux): Adapt. * include/debug/safe_sequence.tcc (_Safe_sequence<>::_M_transfer_from_if): Adapt. Tested under Linux x86_64 debug mode. Ok to commit ? François