[Qt-interest] QAtomicInt and QThread

[Francisco Gonzalez]

2011/6/24 Thiago Macieira <thiago at kde.org>:
> I think you don't understand what "live" means.
>
> The object is now affined to that thread. That means QObject will only allow you
> to use its internals from that thread. Your own data follows your own rules.
>
> Code doesn't belong to any thread.
Ok, I tried to tell that code is executed in some thread. As someone
have pointed out if we use signals and slots with DirectConnection it
will be executed in the thread where the "emit" is executed, while
with QueuedConnection it will be executed in the receiver thread (when
the control returns to the event loop of the receiver's thread).

> You do need a lock to be safe.
>
I know it. But a lock is a part of the code that you can assure will
not be executed until some condition is met. It is achieved i.e. with
a mutex.
The code after a mutex.lock() will be executed when mutex is not
already locked. It is supposed that mutex.lock() works as an atomic
operation to avoid locking in two threads.
>
> No, it won't. The reading of that 64-bit integer is very, very dangerous.
>
>> If we want to modify shared data directly, may we use QAtomicInt to
>> block the part of the code that is writing on the code?
>
> QAtomicInt is not a lock. It protects only itself, and only if you use it
> correctly, using the atomic methods. You didn't do any of those three things.
I know it is not a lock. But some operations on QAtomicInt are
supposed to be atomic. So perhaps the question would be: is "if (( i
== 0)" an atomic operation, beeing "i"  a QAtomicInt? If it is, we
could achieve something "similar" to a lock with a QAtomicInt, and
only similar, as it will block the code of the if condition in all
threads, while the condition is met. While the part of the code that
is changing the data is blocked (in any thread) the read operation
should be safe.

In any case, thanks for the answers.

Francisco Gonzalez