Renode 1.4 UART monitor on Windows 10 not updating in real time on multi-core machines

[AntonKrug]

I noticed the UART writes on Windows are much faster, probably due to buffering?

But now UART is not updating as much, with the mandelbrot example it only updates after everything is done. Because by default every single time the screen is cleared there is nothing else to see for many seconds (no history to scroll) only after it finishes it shows the last image.

Could it be some smart optimization? If something is written to a buffer within last 100ms then delay updating the display by another 100ms as it's probably under heavy updates, but because it's under constant updates it will actually never update.

If I artificially added delays on each frame update then it is updated every single frame, but if I decrease the delay slightly it's never updated again until the whole program finished.

I think it would be better if both implementations would be consistent, on Linux it updates straight away as any changes were made. Or have the buffer/smartness as an optional argument to turn on, but not have it set on by default when the other platform doesn't have it.

[PiotrZierhoffer]

It's probably a side effect of moving to WPF, not anything we added as a feature. We will investigate it

[AntonKrug]

Probably yes, it could be some smartness to make it more efficient? Which looks like is, as the execution finished much faster, but at price no seeing anything and wondering if it got stuck somewhere.

[AntonKrug]

Just tested it with a Win10 VM from here:
https://developer.microsoft.com/en-us/windows/downloads/virtual-machines
And there it updates every single character. So if you are having macs as workstations then a Win10 VM might not be enough to reproduce this problem.

On a positive note, now the Renode 1.4 on Windows 10 works straight away, so no need to install that gtk sharp dependancy as previously.

[AntonKrug]

Yet another update/correction. It has nothing to do with the VM, it was only coincidence that by default the VM had a single core, after giving it more resource it became broken again.

And now I can "fix it" on a native machine as well, after starting renode and giving it affinity of 1 core, the original (update all the time) behaviour is back. Is this maybe a race condition or synching between multiple threads? Even giving the VM 2 cores or the affinity of 2 threads should be enough to "break it". I would say slower, but consistent and predictable results would be better. On Linux even with 32 thread machine the UART behaves as expected.

[PiotrZierhoffer]

Nice findings, this will help a lot! Thanks.

[PiotrZierhoffer]

Fixed in 76934a4. This was due to Terminal spamming WPF with new character events. We changed the way XWT handles GUI events in WPF completely. It may still need some optimizations, and your mileage may vary on different PCs.

[AntonKrug]

I will re-test it after this fix will make into a release.

[AntonKrug]

If I understand the fix correctly instead of spawning each thread instance per character now the it's instancianed only once and then it's used to push all characters through the same instance. Looks much more efficient.

[PiotrZierhoffer]

Not exactly. Dispatch is the usual way of reporting actions for WPF. They are all performed on the GUI thread. Apparently the mechanism of reporting the events is too heavy for our needs, so we reimplemented it. It's not optimal from the design point of view and may be subject of further optimizations.