Quote Originally Posted by high_flyer View Post
Reasonable - sure.
But its hard to tell exactly without getting deeper in to the logic of your application.

The only non related comment I have is that you are locking the mutex basically the hole run() duration, which is not good - it is legal, but it cause your application or parts of the logic to wait longer they they should/could.
You should only mutex where data is accessed, and try to be as atomic as possible.
Thanks - I must point out that the slots (connected to signals triggered by the main window GUI) in the ProcessingThread are quite short and only copy a small amount of data. As I said before, my goal in using the mutexes is merely to make sure the update of the flags/settings is predictable and does not occur in the middle of processing. So it looks like the maximum penalty I would pay is a one iteration delay of run() in updating these flags/settings I guess...
Would you agree?

On a related note: When using mutexes to protect different data in the same thread, should I declare seperate mutexes?

eg:
Qt Code:
  1. void ProcessingThread::run()
  2. {
  3. while(1)
  4. {
  5. frame=grabFrame();
  6. mutex.lock();
  7. if(flag1)
  8. doProcessingOnFrame1(frame,setting1,setting2);
  9. if(flag2)
  10. doProcessingOnFrame2(frame,setting3,setting4);
  11. if(flag3)
  12. doProcessingOnFrame3(frame,setting5,setting6);
  13. mutex.unlock();
  14. emit newFrame(frame);
  15. mutex2.lock();
  16. updateFPSvalue(); // saves current FPS value in a private member (this member is accessed by the GUI thread using a "get" function containing a QMutexLocker)
  17. mutex2.unlock();
  18. }
  19. }
To copy to clipboard, switch view to plain text mode 

Thanks again.