[Development] Question about QCoreApplicationData::*_libpaths
Marco.Bubke at theqtcompany.com
Fri Jan 22 19:02:53 CET 2016
Actually what is happen if I am in the middle of changing a qvector, and then copying the vector in an other thread?
Sent from cellphone, sorry for the typos
On January 22, 2016 18:34:46 Matthew Woehlke <mwoehlke.floss at gmail.com> wrote:
> On 2016-01-22 13:13, Marc Mutz wrote:
>> On Friday 22 January 2016 17:44:40 Thiago Macieira wrote:
>>> On Friday 22 January 2016 11:14:47 Marc Mutz wrote:
>>>> On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote:
>>>>> i'm missing?
>>>> You haven't done the exercise with the int first.
>>> Here's the exercise with int. This is thread-safe:
>>> int f()
>>> return 1;
>>> auto x = f();
>>> No matter how many threads call f(), all of them will get a value from f,
>>> can assign it to a variable and modify without caring what other threads
>>> Replace int with QMap or QString and you have the same behaviour.
>> This part of the discussion was about copying a container. You return a new
>> instance instead. Returning a new instance does not copy, nor move, due to
> The same assertions would hold if Thiago had written:
> int f()
> static int result = 1;
> return result;
> ...or anything else for the body of f().
> And in fact, you're again attacking a straw man. The implementation of
> getMap() was not shown; for all you know, it too might have returned a
> new instance every time. (Probably not, but doesn't matter.)
> What matters is that the result is returned *by value*. It is thread
> safe because it is not a reference, it is a copy. Qt containers are
> likewise thread safe because they behave (in a thread-safe manner) *as
> if* an actual copy was made (even though the actual copy might not
> happen until some time later, if ever).
> Development mailing list
> Development at qt-project.org
More information about the Development