Re: Threads and synchronization
Re: Threads and synchronization
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...
I've got a question as to when to use @synchronized and when it's not
necessary, and when OSMemoryBarrier should be used.
If I have a simple GUI/task thread model (i.e., the task does all the
"work", while the GUI interacts with the user/displays content, etc),
it would seem like a simple lock/flag system would be enough--i.e.,
the GUI sets a variable "start" ), and the task starts up, sending
progress back via performTaskOnMainThread:. As long as the GU and
thread don't want to write to the same piece of memory at the same
time, it would seem there shouldn't be conflicts. I call this
"simple" because there would be clear demarcations as to when each
side writes. I would assume that @synchroize and other more complex
locking systems come into play when multiple threads are being used
or both sides might write at the same time. For OSMemoryBarrier, my
understanding is that it must be used anytime writes happen to shared
memory--if ti's not used, there's no guarantee that the other side
"notices" that the data has changed (i.e., if the GUI sets "start"
to true, the thread may not truly be looking at "start", but at a
register that contains start's value; OSMemoryBarrioer forces the
thread's version of "start" to be current…)
Mark _______________________________________________
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