waggy <hon### [at] handbasketorg> wrote:
> Alternately, threads can update their own counters.  When it's time to
> report, they can read the others and report the total.

  Well, the simplest way of implementing that would be that the rendering
threads update their local counters, and the GUI thread reads all these
counters from time to time (eg. once per second), sums them up and shows
the result. (In C++ these counter variables need to be marked as 'volatile'
to make sure the compiler doesn't optimize the assignment in some way.)

  The interesting question here is if mutexes can be skipped completely
in this situation. *In theory* it's possible that the GUI thread will
read garbage if the rendering thread is updating the count at the exact
same time as the GUI thread is reading it, thus requiring a mutex for
proper behavior.

  However, in practice it will be extremely rare for that coincidence to
happen (and in some computer architectures it might actually not happen
at all, as assigning a single variable and reading it might be atomic
operations in practice, even if done by physically separate CPU cores).
Also, in this particular case, even if it did happen, it would not be
catastrophic: It would only mean that for a second (or so) a random
value would be shown instead of the correct one. (The next time the
value updates, it will probably be correct again.)

  I'd say that it could perfectly well be implemented like this. No mutexes
are needed (so in principle the count could actually be updated as
frequently as the GUI wants with no speed overhead).

-- 
                                                          - Warp

Post a reply to this message