On Jun 10, 2010, at 4:43 AM, Paul H. Hargrove wrote: > One should not ignore the option of POSIX shared memory: shm_open() and > shm_unlink(). When present this mechanism usually does not suffer from > the small (eg 32MB) limits of SysV, and uses a "filename" (in an > abstract namespace) which can portably be up 14 characters in length. > Because shm_unlink() may be called as soon as the final process has done > its shm_open() one can get approximately the safety of the IPC_RMID > mechanism, but w/o being restricted to Linux.
FWIW, with the infrastructure work that Sam did, it would probably be the work of about an hour or two to add shm_open()/etc. into the common sm stuff. > I have used POSIX shared memory for another project and found it works > well on Linux, Solaris (10 and Open), FreeBSD and AIX. That is probably > a narrow coverage than SysV, but still worth consideration IMHO. With > mmap(), SysV and POSIX (plus XPMEM on the SGI Altix) as mechanisms for > sharing memory between processes, I think we have an argument for a > full-blown "shared pages" framework as opposed to just a "mpi_common_sm" > MCA parameter. That brings all the benefits like possibly "failing > over" from one component to another (otherwise less desired) one if some > limit is exceeded. For instance, SysV could (for a given set of > priorities) be used by default, but mmap-on-real-fs could be > automatically selected when the requested/required size exceeds the > shmmax value. That's more-or-less what Sam did. Sam -- if the shmat stuff fails because the limits are too low, it'll (silently) fall back to the mmap module, right? -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
