Re: Threads and synchronization

FROM : Cem Karan
DATE : Thu Aug 10 17:56:42 2006

>>> 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.


You're right, it can be; I was only trying to suggest that there are 
all kinds of nasty problems that you can run into if you aren't careful.

Someday, SOMEDAY, I will finish writing a paper I started detailing 
all kinds of weirdness I've seen using pthreads, most of which is the 
same as NSThreads.  Eh, whenever I finally get around to it...

Thanks,
Cem Karan