https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to François Dumont from comment #4) > For me there is no bug. Standard containers are known to not be thread safe. No, containers are known to be thread-safe, when used correctly. > I don't know what Standard points are talking about it but what I consider > as valid was iterating through the container from different threads. However > in your case you are doing some iterator operations, no matter how simple > they are, in one thread while modifying the container from another and this > require you to put some mutex in place to do so. No it doesn't. Only the main thread accesses the container. The other thread simply reads and writes global iterator objects, which are distinct memory locations from the container and so can be accessed concurrently. See 17.6.5.9 [res.on.data.races]: "-7- Implementations may share their own internal objects between threads if the objects are not visible to users and are protected against data races." > I think you will experiment the same issue with all versions of the Standard > lib, even the oldest ones. Synchronization of the list of iterators has > never been plan to cover this kind of usage which is considered as invalid. No, this is a bug.
