On Sat, Jul 14, 2007 at 01:16:42PM -0400, George Bosilca wrote: > Instead of failing at configure time, we might want to disable the > threading features and the shared memory device if we detect that we > don't have support for atomics on a specified platform. In a non > threaded build, the shared memory device is the only place where we > need support for memory barrier. I'll look in the code to see why we > need support for compare-and-swap on a non threaded build. Proper memory barrier is also needed for openib BTL eager RDMA support.
> > Thanks, > george. > > On Jul 14, 2007, at 1:06 PM, Brian Barrett wrote: > > > On Jul 14, 2007, at 10:53 AM, Dirk Eddelbuettel wrote: > > > >> Methinks we need to fill in a few blanks here, or make do with non- > >> asm > >> solutions. I don't know the problem space that well (being a > >> maintainer > >> rather than upstream developer) and am looking for guidance. > > > > Either way is an option. There are really only a couple of functions > > that have to be implemented: > > > > * atomic word-size compare and swap > > * memory barrier > > > > We'll emulte atomic adds and spin-locks with compare and swap if not > > directly implemented. The memory barrier functions have to exist, > > even if they don't do anything. We require compare-and-swap for a > > couple of pieces of code, which is why we lost our Sparc v8 support a > > couple of releases ago. > > > >> For what it's worth, lam (7.1.2, currently) us available on all build > >> architectures for Debian, but it may not push the (hardware) > >> envelope as > >> hard. > > > > Correct, LAM only had very limited ASM requirements (basically, > > memory barrier on platforms that required it -- like PowerPC). > > > > Brian > > _______________________________________________ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Gleb.
