• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Threads and synchronization
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Threads and synchronization


  • Subject: Re: Threads and synchronization
  • From: "email@hidden" <email@hidden>
  • Date: Wed, 23 Aug 2006 07:59:45 -0700

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


  • Follow-Ups:
    • Re: Re: Threads and synchronization
      • From: "Michael Ash" <email@hidden>
    • Re: Re: Threads and synchronization
      • From: "Shawn Erickson" <email@hidden>
References: 
 >Threads and synchronization (was: Re: Secondary run loops?) (From: Cem Karan <email@hidden>)
 >Re: Threads and synchronization (From: John Stiles <email@hidden>)
 >Re: Threads and synchronization (From: AgentM <email@hidden>)

  • Prev by Date: Re: Get a value from NSTableView and put it in a NSString
  • Next by Date: NSDocument file association question
  • Previous by thread: Re: Threads and synchronization
  • Next by thread: Re: Re: Threads and synchronization
  • Index(es):
    • Date
    • Thread