Re: Threads and synchronization

FROM : AgentM
DATE : Thu Aug 10 19:57:15 2006

On Aug 10, 2006, at 11:36 , John Stiles wrote:

> Cem Karan wrote:

>>> 1. Start a periodic timer in your main thread and use a shared
>>> variable to store progress information. You protect your shared
>>> variables using @synchronized or NSLock objects if necessary (if 
>>> it's
>>> just a 32 bit integer storing progress that's not necessary).

>>
>> Please use locks or @synchronized on everything that's shared, 
>> unless you are utterly certain that there is no way that 
>> corruption of the shared data can ever affect you.  I've seen some 
>> very, very strange problems happen because someone decided that 
>> not locking was OK 'just this once' which can be easily avoided by 
>> locking/synchronizing.
>>
>> And before you say that it's OK because it is just a 32 bit 
>> integer, yes, I HAVE seen weirdness that way too; I'll admit, it 
>> was on a misaligned data access (part of a packed struct), but 
>> still, it CAN bite you!
>>

> It's possible even with aligned stuff. Every time you do "x += y", 
> the generated code reads the value of x out of RAM into a register, 
> modifies it, and then writes it back. There is a brief window of 
> opportunity where some other thread could overwrite its value while 
> you have it in a register, and then your thread will clobber that 
> write.
>
> This issue may be more complicated on Intel where there are "direct-
> to-memory" operations, but the basic principle is still applicable; 
> any time you have the value in a register and you're performing 
> operations on it, you are vulnerable.


To be fair, in this particular circumstance, it shouldn't really 
matter because, if the int holds the percentage done, then if the GUI 
reads 62% in the time window where the thread is reading-and-writing 
the register to make it 63%, no one will care. However:
http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/
library_21.html#SEC360
"In practice, you can assume that int and other integer types no 
longer than int are atomic. You can also assume that pointer types 
are atomic; that is very convenient. Both of these are true on all of 
the machines that the GNU C library supports, and on all POSIX 
systems we know of."

To make it explicit (and potentially expensive), one can use the 
volatile variable directive which may or may not cause a cache flush. 
Also see "sig_atomic_t".

All of this information can be gleaned from books such as Butenhof's 
"Programming with POSIX Threads" and has only peripheral relevance to 
Cocoa- moderator smackdown in 3...2...1...