Does it make sense to use a QSemaphore for acessing data inside the same thread?

[d_stranz]

If you have only one thread, then it is impossible for the value of any variable to change in between writing it and reading it. If you write a value to the variable, it will never change no matter how many times you read it, until you write it again.

I think you don't understand the concept of a thread. It is a single continuous string of execution of instructions from beginning to end. It doesn't matter whether you have branches or loops, signals, slots, whatever, only one instruction ever gets executed at any time. The situation you are imagining, where a variable might get changed in between writing and reading it, within the same thread just simply can't happen. If the read instruction follows the write instruction in the execution sequence, that value that is read will be the value that was just written. There's no way for some gremlin to sneak in and change the value.

So there is absolutely no need for semaphores or any other kind of access protection in a single-threaded program.

But as soon as you create a program with more than one thread, and you share a memory location among them, then if any thread writes to the location, then you must protect it.

[Momergil]

Hello d_stranz,

well, so I was guessing And I imagine that the fact the slot that changes a varible's value was connected to a signal from another thread don't change the situation, correct?

Well, that was my doubt =]

Thanks,

Momergil

[d_stranz]

If your app has only one thread, then all the signals and slots are in that thread. There is no between-threads connection. There is no magic about signals and slots. They are just C++ method calls underneath all the Qt wrappings.