Comments on: Barrier

By: dina

dina — Tue, 26 Jan 2010 20:10:43 +0000

Thanks for this great post. I have been debugging code on multiple platforms and very often need to know what processor is used in the specific platform and what memory synchronizations are missing on that platform(since the bugs are usually caused when the programmer forgets to explicitly add barriers that are not implemented on the platform). Here is the small list I have and would love it if people can add to it:
1. x86, x86-64 : strongly ordered
2. SPARC : Writes are not ordered with respect to reads and writes.
3. Itanium : Writes are not ordered. Reads (?)
4. HPUX : ?

By: Nat!

Nat! — Wed, 29 Jul 2009 12:13:37 +0000

lwsync ? Wasn’t that called isync once ?

I thought that an UNLOCK would imply a sync and that therefore the memory barrier would be redundant ? At least that’s how I implemented it (isync in lock, sync in unlock).

By: Friskywitz

Friskywitz — Mon, 11 Jun 2007 00:59:18 +0000

I got asked several questions pertaining to this exact subject on my third phone interview from Apple Computers.

I said mutex… and should have read this blog first. D’oh!

By: David Casseres

David Casseres — Tue, 13 Mar 2007 04:13:44 +0000

Helluva post, Fish. Thanks.

By: tomsci

tomsci — Thu, 01 Mar 2007 22:14:29 +0000

Cripes, I’m a bit concerned this is the first I recall hearing about memory barriers! I (thought I) knew about out-of-order execution, but the multithreaded implications of that had escaped me.

V interesting post, this is something I’ll file under the category of “Things I hope I never need to use but if I do I now know to go and look it up before even attempting it myself”

By: Asko Kauppi

Asko Kauppi — Mon, 26 Feb 2007 20:18:56 +0000

Having seen the Lua and Io comments, I’ll add to the queue of comments.

Lua does not –as of its standard libraries– take a stand on how multithreading be made. Coroutines it offers are essentially within-the thread elements, and useful as such.

But with a small addon module to allow chunks of code ‘thrown’ to other Lua states, I can see the language scale easily to 1000s of cores, if so wanted. This development is surely favourable to small footprint languages such as it.

Anyone wanting to have a go at N core Lua, send me a line.

By: John D.

John D. — Mon, 26 Feb 2007 15:45:48 +0000

How about an efficient thread safe static initialization? Would this make a difference?

http://avitzur.hax.com/2006/11/efficient_thread_safe_static_i.html

By: Sam

Sam — Thu, 22 Feb 2007 19:58:07 +0000

alex.r.

Fair enough, you can actually replace the need for lazy instanciation, still better than a double-checked lock.

By: alex.r.

alex.r. — Thu, 22 Feb 2007 02:19:37 +0000

Sam:
That implementation may be correct but it is slow, because you are required to acquire a lock for every call to getInstance().

This is useless once the first call has been completed. Let’s pretend Thread 1 and 2 execute in parallel but Thread 1 calls getInstance() right before Thread 2:
Thread 1 : getInstance() : acquires Lock
Thread 2 : getInstance() : waits for lock

If the singleton variable is not null, Thread 1 won’t modify it so there’s no reason for Thread 2 to wait before entering the method.

The “double read” combined with “volatile” makes sure we only get the lock when we actually need it. Locking is an expansive thing to do for no reason.

By: Phil

Phil — Wed, 21 Feb 2007 13:02:57 +0000

Just for the record:

Can Programming Be Liberated from the von Neumann Style?

http://www.stanford.edu/class/cs242/readings/backus.pdf