[Qt-interest] Locking across GUI / Simulation and Signal Slots

[André Somers]

Hi,

What comes to my mind is that it seems that your drawing functions have a 
too direct access to the internal data structures. If you pass around 
pointers to internal data, and there is a chance that another part of your 
program deletes that data, then you obviously have a problem in your design.

There are many ways to get around this, I would say. One such way could be 
using a QObject derived data object to hold your data, and pass a pointer to 
that one around. The nice thing is that you can now use a QPointer instead 
of a regular pointer. This pointer will be reset to 0 automatically upon 
deletion, so your drawing routines can note that the data is no longer there 
and thus that the drawing can be skipped.

Another way it to request the data for the drawing from your data managing 
part of the application when it is actually needed for drawing, instead of 
passing it around when the change occurs. In that case, your drawing 
routines will get the most recent updates automatically, and will also 
notice that there is no data at all to draw.

If  you are using multithreading and the data may have to be accessed from 
different threads at the same time, then you may have to resort to real 
locking. In that case, take a look at QMutex and QMutexLocker for your 
locking needs.

André

"Matthias Pospiech" <matthias.pospiech at gmx.de> wrote in message 
news:49763319.6080705 at gmx.de...
> I have a signal in the simulation class which triggers plotting functions 
> (GUI), which then access the Simulation data.
> However if the plotting coincidences which a reset of the data (which 
> happes at the end of a simulation run, which always also triggers a plot 
> update),
> then it is very likely that while the plotting function is retreiving the 
> data, the same array are deleted -> crash.
>
> Now I do not know how to implement locking. What I do now is this
>
> void MainWindow::updatePlotsTimeSpectrum()
> {
>    Laser->data->setDeleteLocked(true);
>    fillPlot(1, Laser->data->TimeAxis(), Laser->data->TimeAmplitude(), 
> Laser->data->Size());
>    fillPlot(2, Laser->data->SpectralAxis(), 
> Laser->data->SpectralAmplitude(), Laser->data->Size());
>    fillPlot(3, Laser->data->TimeAxis(), Laser->data->TimePhase(), 
> Laser->data->Size());
>    fillPlot(4, Laser->data->SpectralAxis(), Laser->data->SpectralPhase(), 
> Laser->data->Size());   Laser->data->setDeleteLocked(false);
> }
>
> void LaserData::deleteArrays()
> {
>    while (isDeleteLocked)
>        { delay(200);} //!< Wait until Arrays are unlocked
>   delete [] TA;
>    delete [] SA;
>    delete [] AA;
> ...
> }
>
> The best solution would be if I could check directly after the emit which 
> triggers updatePlotsTimeSpectrum(), that this has finished.
> Any usual solution to such a problem?