[Development] Question about QCoreApplicationData::*_libpaths

Matthew Woehlke mwoehlke.floss at gmail.com
Fri Jan 22 15:30:17 CET 2016


On 2016-01-22 05:00, Marc Mutz wrote:
> On Friday 22 January 2016 09:43:17 Иван Комиссаров wrote:
>> Why? In case of QMap, we have no need to use operator= to change the map.
>> We simply detach and insert new data in it.
>> Of course, in case of multiple changes, the map can reach some "invalid
>> state" before changes are finished (i.e. in case we need transacted
>> changes, we have to use mutex anyway). But it is not neccessary in some
>> cases.
> 
>    class IWantToBeThreadSafe {
>        int m_i;
>    public:
>        void setI(int i) { m_i = i; }
>        int i() const { m_i; }
>    };
> 
> Make this class thead-safe (without QAtomicInt :).
> 
> Then replace 'int' with QMap.
> 
> Then you have your answer.

No, you don't. This is a blatant straw man.

The original example returned a pointer-to-map that later¹ found its way
into another thread. If the pointer-to-map was instead a QMap (by-value,
not by-reference), there would be no problem; when someone tries to
modify the map (which is now shared, under the hood, in multiple
threads), a detach happens. The shared map is effectively read only and
the reference is not (atomically) released until the copy completes, so
there is no way for the shared map to be modified while it is shared.
Thus, it is thread safe.

(¹ Or at the same time. We're not talking about whether *calling that
method itself* is thread safe; we would, indeed, need a mutex or other
cleverness for that.)

-- 
Matthew




More information about the Development mailing list