https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #19 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Nicholas Williams from comment #18) > (In reply to Jonathan Wakely from comment #17) > > > > You must stop accessing a global object while it's being destroyed in > > another thread. I really don't know why this needs to be repeated so many > > times. > > Well in this case, at least, it had to be repeated because of *your* > previous and now-allegedly-incorrect statement that I could use > atomic<shared_ptr> to work around this problem: > > > If you need to make copies of a shared_ptr while also modifying it, you need > > to use std::atomic<std::shared_ptr<T>> No, I never said "just swap shared_ptr for atomic<shared_ptr> and it will workaround your broken code". And I never said that you could make copies while *destroying* an object, because you can't, for any type. That's always a data race. The point I was making is the same one that cppreference makes, as quoted above in comment 12. atomic<shared_ptr> allows reading and writing to be atomic. You can't make destruction atomic and it would be useless if you could. Imagine the destructor is "atomic" so cannot interleave with any operations in other threads. Now all your accesses to the object either happen before the destructor (in which case they're safe anyway) or they happen after the destructor (in which case they're accessing an object outside its lifetime, which is undefined). The problem is accessing an object outside its lifetime. Your program fails to ensure that the copies of pInstance all happen before it is destroyed. > As for this: > > > N.B. std::atomic::~atomic() is not an atomic operation > > For my reading, could you link to this? I cannot find any documentation that > specifies one way or another whether ~atomic is atomic. For that matter, It doesn't matter, your program would still be broken because it fails to ensure that every copy of pInstance happens-before it is destroyed. > neither the documentation for std::atomic<T> nor the documentation for the > specialization std::atomic<std::shared_ptr<T>> indicate that a destructor > even exists. It's a class, it always has a destructor even if it's implicitly declared or defined as deleted.
