Prevent concurrent access from different threads?
-
Hi, I was wondering whether I could have some views on the following.
My application uses a thread to run a simulation and generate simulation data. A thread is used so that my application's GUI can remain responsive. Now, while a simulation is being run, my application's main thread makes successive calls to QTimer::singleShot() to fetch any new simulation data that has been generated, as well as to plot whatever the user wants to visualise. The user can decide on what to visualise by creating/removing traces, this through my application's GUI.
If I pre-select some traces and run a simulation, then everything works as expected. However, if, during a simulation, I remove a trace, then my application may crash. This is because the fetching function I call from QTimer::singleShot() goes through all the different traces and update them. Now, if a trace has been removed during a simulation and, more importantly, in the middle of my fetching function, then my fetching function might try to use a trace which doesn't exist anymore, hence the crash.
So, what would you do to avoid this problem? I originally thought I could solve this problem by using a mutex, but that failed and I believe this might be because of my fetching function being called through QTimer::singleShot() and therefore running in its own thread?
Anyway, any idea/help on the above would be much appreciated...
Cheers, Alan.
-
Hi,
Depending on your simulation implementation, i would rather have it sending a signal to tell that new data are available (It avoids polling)
Have another object that handles the traces and would get the simulation results it needs once it receive the signal. You will then only have to protect the reading and writing to the results using either mutex or semaphores.
Hope it helps
-
[quote author="SGaist" date="1361868489"]Depending on your simulation implementation, i would rather have it sending a signal to tell that new data are available (It avoids polling)[/quote]
I agree with you and, to be honest, this is what I did first, but... though things were working fine on Ubuntu and OS X, I experienced some crazy delays on Windows.
Basically, I used to emit a signal every time I had some results ready. This meant many signals being emitted and, in a slot for that signal, I used to update a progress bar (among other things). The end result was that, on Windows, my simulation would run and finish, but my progress bar would still get updated...
In other words, it seems like, on Windows, processing of the signals is / can be painfully slow. I tried to reduce the number of signals being emitted (so that I would end up with updates at a ~50Hz rate), but though not as bad it was still not perfect on Windows.
Anyway, this is the reason I am now polling and that works perfectly fine except for the issue I mentioned in my original message.
[quote author="SGaist" date="1361868489"]Have another object that handles the traces and would get the simulation results it needs once it receive the signal. You will then only have to protect the reading and writing to the results using either mutex or semaphores.[/quote]
I am not sure how that would solve my problem which is about the user being able to add/remove traces at will using the my application's GUI, and this conflicts (in case a trace gets removed) with a function called through QTimer::singleShot() which needs to go through the different traces to update them.
