2007/8/7, Richard Atterer <richard_at_2007.atterer.net>:

> I don't see why this would be the cause... hm, maybe it gets called too
> frequently, so it may cause performance issues? It would be nice to get
> this clarified...

Yes, I hope Daniel or anyone else who knows why this is not recommended can
answer this question.

You may get away without locking, actually: Your own code in the progress
> function can write to a single "nr of bytes downloaded" integer, and the
> GUI only reads that integer. On most multi-processor architectures,
> "syncing" a word of data between processors will appear to be atomic, as
> whole cache lines are synced and they are a multiple of the word size.
> Thus, your GUI thread will never see a mixture of "old" and "updated"
> bytes
> in the word. Of course, the GUI thread will have to poll for changes...
> :-/

Are you sure this is safe, even on multi-processor systems? I find it hard
to believe that the processors (or cores) lock the words they are writing
to... Even though this might be question of nano seconds (or even faster),
there is a possibility that the reading core reads right in between when the
other core is writing the two words needed to form up a 32-bit integer which
I assume is going to be used. This could result in misleading values.

I can agree with you that it's completely safe even without locks when it
comes to single bytes. Now, I don't know what kind of values Alexander
wanted to pass, if it's percentages ranging from 0 to 100 he could use a
uint8_t and everything would be completely safe I believe. Though what he
probably wants is to send the count in downloaded bytes, and this value
would probably need at least a 32-bit integer and that is where we could
introduce a problem. Alexander might also want to let his application
download files larger than 4 GB, thus need a 64-bit integer and the need for
locks would become an even more pressing issue.

Or perhaps multi-core processors nowadays are safe in this manner..?
Received on 2007-08-07