Re: Re: Threads and synchronization
Re: Re: Threads and synchronization
- Subject: Re: Re: Threads and synchronization
- From: "Michael Ash" <email@hidden>
- Date: Wed, 23 Aug 2006 11:47:43 -0400
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:.
You will have to poll this variable to see if it's set, and polling is
bad. Instead, use an NSConditionLock and signal through that, or just
start a new thread every time. This eliminates your one piece of
shared memory and everything becomes simple.
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
This is not the case. OSMemoryBarrier orders memory accesses. On some
architectures (PPC certainly, I don't know about x86), it's possible
that memory stores will be performed in a different order than they
show up in code. So let's say you had this bit of code (it's terrible,
don't copy the design, just for illustration) looping in a thread:
while(!x) ; // do nothing until x is set
printf("y = %d\n", y);
Then you execute this in another thread:
y = 42;
x = 1;
On a multiprocessor system it's possible that the other CPU will see
"x = 1" first. The other thread would then run, and print a stale
value of y. You fix it by inserting an OSMemoryBarrier between the two
assignments.
For a single variable that you need to force out to memory when you
assign to it, mark it as volatile.
The call to OSMemoryBarrier will *probably* force a store to a
non-volatile variable to be performed, but it's not guaranteed and
that's not its purpose.
Mike
_______________________________________________
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