Waveform download progress not updated if instrument transitions trigger from STOP to TRIGGERED without going through RUN state first

[diggit]

I've noticed that the ngscopeclient randomly skips complete waveform download progress.
Rigol scopes are known for their somewhat slow data download, so it is nicely visible there. I am suspecting the culprit to be, that

OscilloscopeChannel::m_downloadState
OscilloscopeChannel::m_downloadProgress

are written from one thread and read from different thread without using proper resource sharing approach (IMO mutex in this case).

[azonenberg]

There's no need for mutexing here because the download progress is a single float variable being read in the second thread. We're not writing the value from multiple places or doing anything that would require atomicity, you simply read whatever the most recently written value is. All CPUs ngscopeclient runs on are cache coherent between multiple cores so there should not be any issues here.

More likely the problem is in the Rigol driver itself not calling ChannelsDownloadStatusUpdate properly (if say a waveform is only a single block in size or something). Or maybe something in the rendering thread is incorrectly blocking on the socket causing the data thread being busy to prevent the screen from refreshing.

[diggit]

Ok, I will dig more into this.

My suspicion about resource sharing issue was due to the fact, the progress sometimes updates (full progress) or no progress is displayed at all.

[diggit]

It looks like PollTrigger has to return TRIGGER_MODE_RUN at least once. If it returns TRIGGER_MODE_TRIGGERED on first poll, download progress is not updated (ChannelsDownloadStatusUpdate is called in a same way in both cases)

[azonenberg]

Aha, OK. So we probably need to update the sidebar code so that it doesn't require a poll cycle of RUN first to show progress.

[azonenberg]

@fredzo I think you wrote the original sidebar progress code, do you have time to have a look at this?

[fredzo]

Sure, I'll take a look at this sometime this week @azonenberg .

[azonenberg]

No rush. v0.1.1 is being released at the tagged commit as soon as we've generated signed builds for all platforms so this will be a v0.2 fix.

[fredzo]

@diggit I was not able to reproduce the behavior you described:

Do you have a specific configuration to reproduce the problem?
Can you share a screen-cast of it ?