• 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: Chris Suter <email@hidden>
  • Date: Thu, 24 Aug 2006 10:01:50 +1000

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,

The current incarnation of x86 processors have a slightly stronger model than PPC processors in that for most instructions, writes will appear in program order. Remember, however, that reads on both PPC and Intel can happen in any order. Intel also won't guarantee that they won't change their memory model for future processors.


For a single variable that you need to force out to memory when you
assign to it, mark it as volatile.

volatile simply disables some of the optimisations the compiler might perform. A global/heap variable without the volatile keyword will still end up with the same end value (it might not see some intermediate writes that the compiler feels it can optimise away). It's not always necessary to mark your variable as volatile; the atomic functions (in the absence of a cast) will give you a compiler warning on passing volatile variables to them so it's worth understanding when you need volatile and when you don't.


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.

Memory barriers do not force anything to go to memory. They just guarantee the ordering. OSMemoryBarrier will include both a read memory barrier (all reads before the barrier will be seen to happen before all reads after the memory barrier) and a write memory barrier meaning that (all writes before the barrier will be seen to happen before all writes after the memory barrier). You often don't need to use OSMemoryBarrier directly since it can often be incorporated into an OSAtomic...Barrier call that you have nearby. Note that the OSAtomic... and OSMemoryBarrier calls don't work on 10.3. (IncrementAtomic et. al are supported though).


If anyone's interested in this stuff they should really read the processor manuals. The Intel one is called something like IA-32 Intel Architecutre Software Developer's Manual and it's volume 3A that has the stuff on multiprocessors.

Whilst I'm at it, I'd like to clarify something said a while back by Chris Kane:

Locking also ensures visibility of data changes. Generally, individual processors are not compelled to inform other processors of changes to data, nor are other processors compelled to pick it up ( into their L1 cache, say). The real trouble comes when some changes are noticed and others are not, possibly resulting in what appears to be an inconsistent state. The special instructions used by locking also ensure timely and consistent visibility of changes.

Individual processors are compelled to inform other processors of changes to date and they are compelled to pick the changes up. This is true for both PowerPC and Intel architectures.


What I think Chris was getting at is that you have to watch the order in which things become visible to other processors which is where memory barriers come in.

All this really is interesting (to me anyway), but if you don't need it, stick with the APIs provided.

- Chris

Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
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

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>)
 >Re: Threads and synchronization (From: "email@hidden" <email@hidden>)
 >Re: Re: Threads and synchronization (From: "Michael Ash" <email@hidden>)

  • Prev by Date: Re: Re: Can't exec from a Cocoa app?
  • Next by Date: Re: MainMenu.nib - MyDocument.nib bindings question...
  • Previous by thread: Re: Re: Threads and synchronization
  • Next by thread: Creating an NSImage from a bitmap
  • Index(es):
    • Date
    • Thread