It's already in the 1.2 !!! I don't know much you care about
performance, but I do. This patch increase by 10% the latency. It
might be correct for the pathscale compiler, but it didn't look as a
huge requirement for all others compilers. A memory barrier for an
initialization and an unlock definitively looks like killing an ant
with a nuclear strike.
How many memory barrier we have now on the critical path ? Are they
all really necessary ? In fact I try to figure out what the problem
is ? Why this doesn't happens with any other compiler ? Is this our
bug or a PathScale compiler bug ? And the last one: What is the
correct way to fix it in a generic way without affecting the
performances by 10%. As a matter of fact, we're already slower than
MPICH2 for shared memory operations, so something is flawed in our
design ...
Thanks,
george.
On Feb 13, 2007, at 4:20 PM, gship...@osl.iu.edu wrote:
Author: gshipman
Date: 2007-02-13 16:20:59 EST (Tue, 13 Feb 2007)
New Revision: 13644
Modified:
trunk/opal/include/opal/sys/atomic_impl.h
Log:
use memory barriers for lock init and unlock
Modified: trunk/opal/include/opal/sys/atomic_impl.h
======================================================================
========
--- trunk/opal/include/opal/sys/atomic_impl.h (original)
+++ trunk/opal/include/opal/sys/atomic_impl.h 2007-02-13 16:20:59
EST (Tue, 13 Feb 2007)
@@ -337,6 +337,7 @@
opal_atomic_init( opal_atomic_lock_t* lock, int value )
{
lock->u.lock = value;
+ opal_atomic_mb();
}
@@ -368,6 +369,7 @@
OPAL_ATOMIC_LOCKED, OPAL_ATOMIC_UNLOCKED);
*/
lock->u.lock=OPAL_ATOMIC_UNLOCKED;
+ opal_atomic_mb();
}
#endif /* OPAL_HAVE_ATOMIC_SPINLOCKS */
_______________________________________________
svn mailing list
s...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/svn
"Half of what I say is meaningless; but I say it so that the other
half may reach you"
Kahlil Gibran
