Comments on: Please Don’t Rely on Memory Barriers for Synchronization!

By: Crest

Crest — Sat, 04 Aug 2007 21:38:36 +0000

The used Instructions (sync, lwsync, eieio) are not vendor specific but architecture specific as every assembler code is by design. The PowerPC specification does offer some freedom to implementors e.g. to implement fsel but the syncronisation primitives aren’t optional and their semantic is well defined. Nevertheless the critisiced article is no suited for beginners as it encouraged premature optimations.

By: Sitsofe Wheeler

Sitsofe Wheeler — Sun, 10 Jun 2007 20:34:21 +0000

You aren’t the only one warning against casual use of memory barriers. There’s a warning that many people wind up misusing them in Linux kernel drivers too over here: http://zaitcev.livejournal.com/144041.html . It seems that intuitive usage of them doesn’t tend towards correctness even with experienced (but non-parallel expert) programmers…

By: Peter Holditch's Blog

Peter Holditch's Blog — Wed, 04 Apr 2007 21:58:17 +0000

The morning after……

Roaming the blogosphere, as I all too seldom do, I often feel like a party-goer the morning after a major rave-up… Stumbling between different points of view and commentary, finding interesting tidbits here and there as I pass by. On…

By: Andrew Miehs

Andrew Miehs — Thu, 01 Mar 2007 12:15:24 +0000

I don’t think that the ridiculous fish article was trying to say that ‘memory barriers’ are the only way to do things - I think it was more a case of ‘be careful’ and ‘look - when I poke the machine, it pokes me back’.

Most of the articles on his page are to do with ‘performance’ - and I think most people would see this article as a performance vs portability tradeoff.

By: alexr

alexr — Thu, 22 Feb 2007 17:33:28 +0000

“Locks are the only safe and portable solution”

Unfortunately, I can’t agree with you on this. There is a time and place for hardware atomic primitives including memory barriers. Perhaps in a Cocoa app as shown on the ridiculous_fish site is not the best place, but assuming a POSIX threading model there would be incorrect as well.

Cocoa (Foundation) has the NSThread abstraction, which is the proper place for syncronization techniques related to whatever the underlying threading model is. (NSLock, NSConditionLock, etc.) It is an oversight by the AppKit team that lower-level operations are not supplied in the framework, although portable ones are supplied by libkern below it that could probably be assumed to exist for a Cocoa application. ($5 says they’re already implemented on the ARM port for the iPhone.)

Additionally, recent versions of GCC implement quite a full suite of atomic operations like compare_and_swap in the backend such that if one can assume GCC as a compiler, one can assume that these operations are available in a fairly portable fashion. It is a simple exercise to produce a set of macros that convert these calls into those implemented in Visual Studio or many other compilers which now increasingly provide access to hardware atomic primitives.

By: Phil Dawes’ Stuff » Blog Archive » Multithreading links

Phil Dawes’ Stuff » Blog Archive » Multithreading links — Thu, 22 Feb 2007 10:43:18 +0000

[…] Then a followup re-adjusting newbies to the complexities of using memory barriers for synchronisation. […]

By: Benjamin Ragheb

Benjamin Ragheb — Wed, 21 Feb 2007 19:15:07 +0000

Shawn why are you rolling your eyes at my attitude? I am not angry at all. I am very grateful that there are people like Michael on the Internet to warn people like myself about information that could be dangerous to people who are not as smart as he is. The only thing that would be better is if the smarter people could keep that stuff away from the Internet to begin with so people like me would not run the risk of reading it in the first place.

By: Paul Davis

Paul Davis — Wed, 21 Feb 2007 16:01:44 +0000

Just a quick note: the fact that POSIX doesn’t define atomic operations doesn’t mean that they cannot be implemented in a portable fashion. glib, the linux kernel and several other libraries all contain a useful set of atomic operations that use architecture specific memory barriers and other techniques.

Its unfortunate that PThreads didn’t include this functionality. As much as advocate of PThreads as I am, I see this as the POSIX committee’s issue and not mine, and feel free to use atomic operations in my code, portably.

I also think that those of us who do real-time development with threads in which we cannot take afford to take locks and have thus been forced to grapple with lock-free but safe programming techniques need to spread the news about what we do a little more widely.

By: Shawn Erickson

Shawn Erickson — Tue, 20 Feb 2007 23:18:59 +0000

Wow why all the anger at what Michael posted… he is correct in his assessment that you should only start doing stuff like this when you find that you really need to (for performance reasons) and that the post on ridiculous fish is a little to light on the warnings about doing this.

You often will get better performance increases by changing algorithms (after profiling) then attempting to avoid locks using tricks various tricks.

Oh Benjamin nice attitude… *rolls eyes*

By: Benjamin Ragheb

Benjamin Ragheb — Tue, 20 Feb 2007 18:16:42 +0000

I am so glad you posted this, since you are so smart you can point out how dangerous the information on the Ridiculous Fish blog is when read by people who aren’t as smart as you. I will admit I was disappointed, however, that you didn’t make your criticism more portable, so I wouldn’t have to modify it to apply to the specific details of other blogs I read.