RE: Threads and synchronization
RE: Threads and synchronization
- Subject: RE: Threads and synchronization
- From: "John Stiles" <email@hidden>
- Date: Thu, 10 Aug 2006 11:17:53 -0700
- Thread-topic: Threads and synchronization
The glibc manual has a nugget of truth there, but it's highly misleading. There are a bunch of unstated qualifiers at work:
- The data must be at natural alignment (which is not always the case; witness most structures from the Carbon layer, which use the tighter 68K alignment). Otherwise, a write may straddle a cacheline, and this can introduce all sorts of serious non-atomic behavior.
- Typical -O2 code will often read a value into a register at the beginning of a function, operate on it for as long as it wants, and then only write it back out at the end of a function. Obviously this is not atomic behavior.
- Probably other issues with caches that I'm not going to bother considering right now :)
While it's true that the basic operations of "read an aligned longword" and "write an aligned longword" will never be interrupted mid-read or mid-write, that is a weak guarantee; it's not good enough to ensure that your average compiled C code will be perfectly functional.
-----Original Message-----
From: cocoa-dev-bounces+jstiles=email@hidden on behalf of AgentM
Sent: Thu 8/10/2006 10:57 AM
To: email@hidden
Subject: Re: Threads and synchronization
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...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden