Comments on: Barrier

By: Mark Travis

Mark Travis — Fri, 02 Apr 2010 08:53:57 +0000

I think I found an answer to my question–as long as proper fencing is done, such as mfence on x86, prior to the attempted read (LOAD) in thread 2, then the correct value should be referenced by the destination pointer.

Any mutex should do the trick, since I understand that pthread_mutex_lock calls a load-store barrier whenever it’s invoked.

By: Mark Travis

Mark Travis — Wed, 31 Mar 2010 06:53:18 +0000

I typo’d my above pseudo-code.

thread 1 should read as follows:
payload=5;
srcptr=&payload;

pthread_mutex_lock(&whatevermutex);
queueptr=srcptr;
pthread_mutex_unlock(&whatevermutex);

————————-

Thanks

By: Mark Travis

Mark Travis — Wed, 31 Mar 2010 06:44:41 +0000

I’m working on a project involving mutexes. I suspect that I’m doing it wrong, but I can’t seem to force data inconsistency in my own tests. I’m basically doing message passing of arbitrary data, as follows:

Here’s what I’m basically doing:

int srcpayload, destpayload;
int *srcptr, *queueptr, *destptr;

thread 1:
payload=5;
srcptr=&payload;

pthread_mutex_lock(&whatevermutex);
srcptr=queueptr;
pthread_mutex_unlock(&whatevermutex);

thread 2:
pthread_mutex_lock(&whatevermutex);
destptr=queueptr;
pthread_mutex_unlock(&whatevermutex);

destpayload=*destptr;

————————–

What I want is for destpayload to always equal srcpayload. But since I’m only copying pointers within mutex locks, I’m afraid that it’s possible that the assignment of the payload to the pointer might not be guaranteed to be correct on the destination side. Is pthreads’ mutex logic smart enough to ensure that any assignment of a value to a pointer’s destination is within a proper memory barrier? My development platform is Linux on amd64, but I want to do the right thing from a portability standpoint.

You seem like a guy (guys?) (gal?) (gal-guys?) who would know this.

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