Progress Dialog: Fix race that could lead to ever-inaccurate results

[elad335]

• Fix state atomicity: this is similar to how SPU GETLLAR works by loading all the values again and comparing to old state to check for whole load-atomicity of multiple values in a lock-free manner.
• Avoid PPU compilation pop-up on short linkage.

[Megamouse]

Why?

[Megamouse]

Why?

[Megamouse]

And why should that make any difference?
It may change a nanosecond later.

[elad335]

Before (race example in steps):

1. Progress dialog loads nullptr text.
2. Progress dialog loads ptotal. Let's say it is equal to X. pdone is equal to X as well here.
3. A PPU thread is about to compile a module, sets text and incrementes both ptotal and pdone.
4. Progress dialog loads pdone, pdone value in thread is now eqaul to X + 1, ptotal value in thread is X. In reality they are both X + 1.
5. Progress dialog exists the loop, resets them all. now pdone is ever lagging by 1.

After:

1. Progress dialog loads nullptr text.
2. Progress dialog loads ptotal. Let's say it is equal to X. pdone is equal to X here as well here.
3. A PPU thread is about to compile a module, sets text and incremenetes both ptotal and pdone.
4. Progress dialog loads pdone, pdone value in thread is now eqaul to X + 1, ptotal value in thread is X. In reality they are both X + 1.
5. Progress dialog sees value mismatch, restarts loads and gets equal ptotal and pdone and does not exit the loop.

Another example:
Before:

1. Progress dialog loads nullptr text.
2. A PPU thread is about to compile a module, sets text and incrementes both ptotal and pdone.
3. Progress dialog loads pdone, pdone value in thread is now eqaul to X + 1, ptotal value in thread is X + 1. In reality they are both X + 1.
4. Progress dialog loads ptotal. Let's say it is equal to X + 1. pdone is equal to X as well here.
5. Progress dialog exists the loop, resets them all. now both pdone and ptotal are ever lagging by 1.

After:

1. Progress dialog loads nullptr text.
2. A PPU thread is about to compile a module, sets text and incrementes both ptotal and pdone.
3. Progress dialog loads pdone, pdone value in thread is now eqaul to X + 1, ptotal value in thread is X + 1. In reality they are both X + 1.
4. Progress dialog loads ptotal. Let's say it is equal to X + 1. pdone is equal to X as well here.
5. Progress dialog sees value mismatch, restarts loads and gets equal ptotal and pdone and does not exit the loop.

TLDR: Thread-safety is a headache.

[Megamouse]

That's purely random now, same as before, if this loop runs faster than the next change is supplied.
There's zero thread safety here.

You should've just used a struct with a mutex and call it a day.

[elad335]

No there is no race here now. The fact that SPU does not crash for games is a live example for it. GETLLAR is an atomic 128-byte load. This loop recheck is a technique to load atomicaly any amount of bytes without a mutex.

[Megamouse]

This could've easily been optimized into another scope