Re: Threads and synchronization
Re: Threads and synchronization
- Subject: Re: Threads and synchronization
- From: AgentM <email@hidden>
- Date: Thu, 10 Aug 2006 13:57:15 -0400
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