Re: Re: Threads and synchronization
Re: Re: Threads and synchronization
- Subject: Re: Re: Threads and synchronization
- From: "Shawn Erickson" <email@hidden>
- Date: Wed, 23 Aug 2006 08:29:38 -0700
On 8/23/06, email@hidden <email@hidden> wrote:
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
You likely shouldn't use OSMemoryBarrier in any of your application
code directly but instead use things like @synchroize or locks as
needed, those will do the right thing for you.
(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…)
A register cached version of "start" is something the compiler may
optimize your code to do (for example in a loop with no external code
execution). OSMemoryBarrier wont deal with that directly however
compilers know that if you call any external code (external to that
block) then any non-local data it has cached in registers could now be
out of sync with what is in RAM. As a result the compiler will inject
loads into your code as needed if external code is executed.
Additionally you can consider using the volatile key word but often it
isn't needed.
I personally recommend using sensible (visible and explicit) locking
constructs to protect shared resources and data if they will be used
by multiple threads. Avoid doing any tricks so that the code is
resilient to future modifications (that may break the assumptions you
put in place at one point) and obviously easier to read. Only if you
see a performance impact in an important area then go back an modify
your locking using various tricks and advanced methods.
...of course as Chris stated some of the best multi-threaded
applications have logic designed such that little to no shared
resources and/or data needs to be protect by locks. (for example
sometimes it makes sense to burn a little more memory if you can avoid
locking)
A thing I like to do is bound coherency domains around a thread. In
other words design things such that a given thread is responsible for
modifying a given data structure and all other threads shuffle work to
that thread when modification is needed.
-Shawn
_______________________________________________
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