is it a multi-threaded process (logic seems to dictate that it would be)

If so, I think there's a slight bug (Very minor issue) in the reporting because
on my dual-core machine it seems to be reporting two different values
alternately.

My almost non-existent knowledge of parallel processing is giving me the notion
that each thread is printing separately.

Feel free to relieve my ignorance if I'm wrong.

A.D.B.

Post a reply to this message

Le 06/01/2011 09:27, Anthony D. Baye a écrit :
> is it a multi-threaded process (logic seems to dictate that it would be)
> 
> If so, I think there's a slight bug (Very minor issue) in the reporting because
> on my dual-core machine it seems to be reporting two different values
> alternately.
> 
> My almost non-existent knowledge of parallel processing is giving me the notion
> that each thread is printing separately.

Two threads updating the same counter would need a mutex to protect the
counter, defeating the purpose of multi-threading (well, the mutex would
become the bottleneck).

IMHO, the report of the increasing counter(s) is just to make the user
happy about the progress. It has no added value when compared to a
rotating bar ( | / - \ ). But even a rotating bar updated by 2 or more
threads would need a mutex to provide the rotation. In fact even a
flashing char ("*" alternating with a space) would flash at irregular
interval with multiple threads and no mutex.

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Two threads updating the same counter would need a mutex to protect the
> counter, defeating the purpose of multi-threading (well, the mutex would
> become the bottleneck).

  If the count is updated infrequently (eg. once per second) it shouldn't
make any difference.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Le_Forgeron <lef### [at] freefr> wrote:
> > Two threads updating the same counter would need a mutex to protect the
> > counter, defeating the purpose of multi-threading (well, the mutex would
> > become the bottleneck).
>
>   If the count is updated infrequently (eg. once per second) it shouldn't
> make any difference.
>
Agreed.  Alternately, threads can update their own counters.  When it's time to
report, they can read the others and report the total.

Post a reply to this message

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

On 6/01/2011 19:27, Anthony D. Baye wrote:
> is it a multi-threaded process (logic seems to dictate that it would be)
> 
> If so, I think there's a slight bug (Very minor issue) in the reporting because
> on my dual-core machine it seems to be reporting two different values
> alternately.
> 
> My almost non-existent knowledge of parallel processing is giving me the notion
> that each thread is printing separately.

Close: what is in fact happening is each thread is sending its own stats to
the front-end code separately (we have a message-passing system); the issue
with separate counts is known and will be resolved prior to final release.

-- Chris

Post a reply to this message