> No. When you call detach(), you're in a mutating function of the object > and you can assume that you're the only thread executing on a member > function of that thread, because if that's not the case, you're in UB > land. Only const methods are allowed to execute concurrently on the same > object. Mutators must get exclusive access.
Absolutly right, but a method "isDetached()" which is const has no usefulness on its own, independently from a detach() procedure. This is the purpose of my orginal remark. Philippe On Thu, 08 Aug 2019 12:00:11 +0300 "Mutz, Marc via Development" <development@qt-project.org> wrote: > On 2019-08-08 11:29, Philippe wrote: > > Yet, what is the usefullness of qIntrusiveDetached()? > > qIntrusiveDetached() makes it possible to use std::atomic ref counts > (which don't have ref() and deref()). It's separate from > qIntrusiveClone() because the latter is more often overloaded than the > former (cf. QTimeZone followup change). > > > Because the result depends on a relaxed load, hence the moment after > > qIntrusiveDetached() was evaluated, rechecking qIntrusiveDetached() > > could give a different result. > > No. When you call detach(), you're in a mutating function of the object > and you can assume that you're the only thread executing on a member > function of that thread, because if that's not the case, you're in UB > land. Only const methods are allowed to execute concurrently on the same > object. Mutators must get exclusive access. > > HTH, > Marc > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
