Doc > Qt 4.8 > Mandelbrot Example
-
wrote on 13 Mar 2016, 15:00 last edited by
In this example Mandelbrot Example | Qt 4.8, in function RenderThread::run() why we don't protect the image member by a mutex? We write image here and read it in other thread, in function MandelbrotWidget::updatePixmap(const QImage &image, double scaleFactor). So why its not conflict?
-
Hi and welcome to devnet,
Because each time you pass in the loop a new image is created so you are not accessing a shared resource.
-
Hi and welcome to devnet,
Because each time you pass in the loop a new image is created so you are not accessing a shared resource.
wrote on 14 Mar 2016, 15:33 last edited by@SGaist you mean forever loop or while (pass < NumPasses) loop?
-
The forever loop contains the
while (pass < NumPasses) -
Hi and welcome to devnet,
Because each time you pass in the loop a new image is created so you are not accessing a shared resource.
wrote on 15 Mar 2016, 13:43 last edited by -
The forever loop
-
wrote on 15 Mar 2016, 16:59 last edited by
Ok, but after emitting the signal we go to the next iteration of the while (pass < NumPasses) and write to the same image. And we read it in another thread at the same time.
-
From the documentation of the example: "With queued connections, Qt must store a copy of the arguments that were passed to the signal so that it can pass them to the slot later on."
-
wrote on 16 Mar 2016, 12:41 last edited by
Thank you!
-
You're welcome !
Since it's all clear now, please mark the thread as solved using the "Topic Tool" button so that other forum users may know an answer has been found :)
10/10