- discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Problem with SystemStubs under Mac OS X 10.7.5.
by Douglas Dommermuth 23 Feb '13

23 Feb '13

Hello Dave, It was a silly mistake on my part. I had an old mpif90 in /usr/local/bin/. The most recent release of mpich puts mpif90 in another area. I did not realize. I have been using mpich for so long, I did not realize the change. Thanks for pointing me in the right direction. Thank you, Doug. On Feb 23, 2013, at 10:31 AM, Douglas Dommermuth wrote: > Hello Dave, > > Did I correctly configure the build: > > ./configure --prefix=/Users/dougdommermuth/mpich2/mpich-install CC=/usr/bin/icc FC=/usr/bin/ifort | & tee c.txt > > When I look at the commands that you just sent me, it seems to be pointing to an older version of Fortran, whereas my logical links are as follows: > > [dgd]% ls -al /usr/bin/ifort > lrwxr-xr-x 1 root wheel 19 Feb 23 08:21 /usr/bin/ifort -> /usr/bin/ifort-13.0 > [dgd]% ls -al /usr/bin/ifort-13.0 > lrwxr-xr-x 1 root wheel 42 Feb 23 08:21 /usr/bin/ifort-13.0 -> /usr/bin/ifort-13.0-base/bin/intel64/ifort > > Thank you, Doug. > > > On Feb 23, 2013, at 10:13 AM, Dave Goodell wrote: > >> On Feb 23, 2013, at 11:52 AM CST, Douglas Dommermuth wrote: >> >>> I have attached the files that you requested (files.tar.gz). I could not find this file: mpich-3.0.2/src/pm/hydra/tools/topo/hwloc/hwloc/config.log. The output for compling pi3f90.f90 is below: >>> >>> mpif90 pi3f90.f90 >>> ld: library not found for -lSystemStubs >> >> Did you upgrade to 10.7 (Lion) without reinstalling the Intel Fortran compiler? Most of the google hits I'm getting about this indicate that it can happen when: >> >> 1) you have an ifort version <12.1; or >> >> 2) you installed ifort, then upgraded from 10.6 (or earlier) to 10.7 (or later). >> >> Obviously, #1 does not appear to apply to you. So maybe #2 does? >> >> We do have some logic to add "-lSystemStubs" to the link line in certain circumstances, but your config.log file is showing that we are not doing that in your case: >> >> ----8<---- >> pac_cv_prog_f77_and_c_stdio_libs=none >> […] >> pac_cv_prog_fc_and_c_stdio_libs=none >> ----8<---- >> >> Further debug might be accomplished by inspecting the output of these two commands: >> >> ----8<---- >> mpif90 -show pi3f90.f90 >> mpif90 -v pi3f90.f90 >> ----8<---- >> >> The first will show the ifort command that MPICH intends to execute. The second will show the commands that the ifort compiler driver executes as it attempts to compile your program. This should show us which part of the stack is incorrectly adding "-lSystemStubs" to your link line. My guess is that it's your ifort install, based on the other information that you have sent so far. >> >> -Dave >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Re: [mpich-discuss] Problem with SystemStubs under Mac OS X 10.7.5.
by Douglas Dommermuth 23 Feb '13

23 Feb '13

Hello Dave, Did I correctly configure the build: ./configure --prefix=/Users/dougdommermuth/mpich2/mpich-install CC=/usr/bin/icc FC=/usr/bin/ifort | & tee c.txt When I look at the commands that you just sent me, it seems to be pointing to an older version of Fortran, whereas my logical links are as follows: [dgd]% ls -al /usr/bin/ifort lrwxr-xr-x 1 root wheel 19 Feb 23 08:21 /usr/bin/ifort -> /usr/bin/ifort-13.0 [dgd]% ls -al /usr/bin/ifort-13.0 lrwxr-xr-x 1 root wheel 42 Feb 23 08:21 /usr/bin/ifort-13.0 -> /usr/bin/ifort-13.0-base/bin/intel64/ifort Thank you, Doug. On Feb 23, 2013, at 10:13 AM, Dave Goodell wrote: > On Feb 23, 2013, at 11:52 AM CST, Douglas Dommermuth wrote: > >> I have attached the files that you requested (files.tar.gz). I could not find this file: mpich-3.0.2/src/pm/hydra/tools/topo/hwloc/hwloc/config.log. The output for compling pi3f90.f90 is below: >> >> mpif90 pi3f90.f90 >> ld: library not found for -lSystemStubs > > Did you upgrade to 10.7 (Lion) without reinstalling the Intel Fortran compiler? Most of the google hits I'm getting about this indicate that it can happen when: > > 1) you have an ifort version <12.1; or > > 2) you installed ifort, then upgraded from 10.6 (or earlier) to 10.7 (or later). > > Obviously, #1 does not appear to apply to you. So maybe #2 does? > > We do have some logic to add "-lSystemStubs" to the link line in certain circumstances, but your config.log file is showing that we are not doing that in your case: > > ----8<---- > pac_cv_prog_f77_and_c_stdio_libs=none > […] > pac_cv_prog_fc_and_c_stdio_libs=none > ----8<---- > > Further debug might be accomplished by inspecting the output of these two commands: > > ----8<---- > mpif90 -show pi3f90.f90 > mpif90 -v pi3f90.f90 > ----8<---- > > The first will show the ifort command that MPICH intends to execute. The second will show the commands that the ifort compiler driver executes as it attempts to compile your program. This should show us which part of the stack is incorrectly adding "-lSystemStubs" to your link line. My guess is that it's your ifort install, based on the other information that you have sent so far. > > -Dave > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Problem with SystemStubs under Mac OS X 10.7.5.
by Douglas Dommermuth 23 Feb '13

23 Feb '13

Hello Dave, ifort was installed after the upgrade to 10.7. Here is the output that you requested: [dgd]% mpif90 -show pi3f90.f90 /opt/intel/Compiler/11.0/059/bin/intel64/ifort pi3f90.f90 -I/usr/local/include -I/usr/local/include -L/usr/local/lib -lmpichf90 -lmpichf90 -lpmpich -lmpich [dgd]% mpif90 -v pi3f90.f90 mpif90 for 1.0.8p1 Version 11.0 /opt/intel/Compiler/11.0/059/bin/intel64/fortcom -D__INTEL_COMPILER=1100 -D_MT -D__INTEL_COMPILER_BUILD_DATE=20090131 -D__PIC__ -D__pic__ -D__APPLE__ -D__MACH__ -D__x86_64 -D__x86_64__ -mGLOB_pack_sort_init_list -I. -I/usr/local/include -I/usr/local/include -I/opt/intel/Compiler/11.0/059/include/intel64 -I/opt/intel/Compiler/11.0/059/include -I/usr/local/include -I/usr/include -O2 -mP1OPT_version=1100 -mGLOB_diag_file=/var/folders/dg/8sf80tms373_179jg3_sjb700000gn/T//ifortK2SDC0.diag -mGLOB_diag_use_message_catalog=FALSE -mGLOB_source_language=GLOB_SOURCE_LANGUAGE_F90 -mGLOB_tune_for_fort -mGLOB_use_fort_dope_vector -mP2OPT_static_promotion -mP1OPT_print_version=FALSE -mP3OPT_use_mspp_call_convention -mCG_use_gas_got_workaround=F -mP2OPT_align_option_used=TRUE "-mGLOB_options_string=-I/usr/local/include -I/usr/local/include -v -L/usr/local/lib -lmpichf90 -lmpichf90 -lpmpich -lmpich" -mGLOB_position_independent_code -mGLOB_preemption_model=1 -mGLOB_cxx_limited_range=FALSE -mP2OPT_eh_nirvana -mGLOB_as_output_backup_file_name=/var/folders/dg/8sf80tms373_179jg3_sjb700000gn/T//ifortfAUyYsas_.s -mIPOPT_activate -mIPOPT_lite -mGLOB_machine_model=GLOB_MACHINE_MODEL_EFI2 -mGLOB_extended_instructions=0x80 -mGLOB_advanced_optim=TRUE -mP2OPT_subs_out_of_bound=FALSE -mGLOB_ansi_alias -mIPOPT_args_in_regs=0 -mPGOPTI_value_profile_use=T -mP2OPT_hlo_level=2 -mP2OPT_hlo -mPAROPT_par_report=1 -mIPOPT_obj_output_file_name=/var/folders/dg/8sf80tms373_179jg3_sjb700000gn/T//ifortK2SDC0.o -mGLOB_os_target=GLOB_OS_TARGET_MACH -mGLOB_obj_output_file=/var/folders/dg/8sf80tms373_179jg3_sjb700000gn/T//ifortK2SDC0.o -mGLOB_source_dialect=GLOB_SOURCE_DIALECT_FORTRAN -mP1OPT_source_file_name=pi3f90.f90 pi3f90.f90 ld -lcrt1.10.5.o -dynamic -arch x86_64 -weak_reference_mismatches non-weak -o a.out /opt/intel/Compiler/11.0/059/lib/for_main.o /var/folders/dg/8sf80tms373_179jg3_sjb700000gn/T//ifortK2SDC0.o -L/usr/local/lib -lmpichf90 -lmpichf90 -lpmpich -lmpich -L/opt/intel/Compiler/11.0/059/lib -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64/ -L/usr/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/ -L/usr/lib/i686-apple-darwin11/4.2.1/ -L/usr/lib/ -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/ -L/usr/llvm-gcc-4.2/bin/../lib/gcc/ -L/usr/lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/usr/lib/gcc/i686-apple-darwin11/4.2.1/ -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/../../../ /opt/intel/Compiler/11.0/059/lib/libifport.a /opt/intel/Compiler/11.0/059/lib/libifcore.a /opt/intel/Compiler/11.0/059/lib/libimf.a /opt/intel/Compiler/11.0/059/lib/libsvml.a /opt/intel/Compiler/11.0/059/lib/libipgo.a -lgcc -lgcc_s.10.5 -lgcc -lSystemStubs -lmx -lSystem /opt/intel/Compiler/11.0/059/lib/libirc.a -lpthread /opt/intel/Compiler/11.0/059/lib/libirc_s.a -ldl ld: library not found for -lSystemStubs rm /var/folders/dg/8sf80tms373_179jg3_sjb700000gn/T//ifort0dZe82sw_vers rm /var/folders/dg/8sf80tms373_179jg3_sjb700000gn/T//ifortTuSifnlibgcc rm /var/folders/dg/8sf80tms373_179jg3_sjb700000gn/T//ifortbjjEHSgnudirs rm /var/folders/dg/8sf80tms373_179jg3_sjb700000gn/T//ifortbRSAZfdashv rm /var/folders/dg/8sf80tms373_179jg3_sjb700000gn/T//ifortvkktfoos rm /var/folders/dg/8sf80tms373_179jg3_sjb700000gn/T//ifortKKRMkztos rm /var/folders/dg/8sf80tms373_179jg3_sjb700000gn/T//ifortfAUyYsas_.s rm /var/folders/dg/8sf80tms373_179jg3_sjb700000gn/T//ifortRu8NBdarg rm /var/folders/dg/8sf80tms373_179jg3_sjb700000gn/T//iforthbU583gnudirs rm /var/folders/dg/8sf80tms373_179jg3_sjb700000gn/T//ifortK2SDC0.o Thank you, Doug. On Feb 23, 2013, at 10:13 AM, Dave Goodell wrote: > On Feb 23, 2013, at 11:52 AM CST, Douglas Dommermuth wrote: > >> I have attached the files that you requested (files.tar.gz). I could not find this file: mpich-3.0.2/src/pm/hydra/tools/topo/hwloc/hwloc/config.log. The output for compling pi3f90.f90 is below: >> >> mpif90 pi3f90.f90 >> ld: library not found for -lSystemStubs > > Did you upgrade to 10.7 (Lion) without reinstalling the Intel Fortran compiler? Most of the google hits I'm getting about this indicate that it can happen when: > > 1) you have an ifort version <12.1; or > > 2) you installed ifort, then upgraded from 10.6 (or earlier) to 10.7 (or later). > > Obviously, #1 does not appear to apply to you. So maybe #2 does? > > We do have some logic to add "-lSystemStubs" to the link line in certain circumstances, but your config.log file is showing that we are not doing that in your case: > > ----8<---- > pac_cv_prog_f77_and_c_stdio_libs=none > […] > pac_cv_prog_fc_and_c_stdio_libs=none > ----8<---- > > Further debug might be accomplished by inspecting the output of these two commands: > > ----8<---- > mpif90 -show pi3f90.f90 > mpif90 -v pi3f90.f90 > ----8<---- > > The first will show the ifort command that MPICH intends to execute. The second will show the commands that the ifort compiler driver executes as it attempts to compile your program. This should show us which part of the stack is incorrectly adding "-lSystemStubs" to your link line. My guess is that it's your ifort install, based on the other information that you have sent so far. > > -Dave > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Problem with SystemStubs under Mac OS X 10.7.5.
by Dave Goodell 23 Feb '13

23 Feb '13

On Feb 23, 2013, at 11:52 AM CST, Douglas Dommermuth wrote: > I have attached the files that you requested (files.tar.gz). I could not find this file: mpich-3.0.2/src/pm/hydra/tools/topo/hwloc/hwloc/config.log. The output for compling pi3f90.f90 is below: > > mpif90 pi3f90.f90 > ld: library not found for -lSystemStubs Did you upgrade to 10.7 (Lion) without reinstalling the Intel Fortran compiler? Most of the google hits I'm getting about this indicate that it can happen when: 1) you have an ifort version <12.1; or 2) you installed ifort, then upgraded from 10.6 (or earlier) to 10.7 (or later). Obviously, #1 does not appear to apply to you. So maybe #2 does? We do have some logic to add "-lSystemStubs" to the link line in certain circumstances, but your config.log file is showing that we are not doing that in your case: ----8<---- pac_cv_prog_f77_and_c_stdio_libs=none […] pac_cv_prog_fc_and_c_stdio_libs=none ----8<---- Further debug might be accomplished by inspecting the output of these two commands: ----8<---- mpif90 -show pi3f90.f90 mpif90 -v pi3f90.f90 ----8<---- The first will show the ifort command that MPICH intends to execute. The second will show the commands that the ifort compiler driver executes as it attempts to compile your program. This should show us which part of the stack is incorrectly adding "-lSystemStubs" to your link line. My guess is that it's your ifort install, based on the other information that you have sent so far. -Dave

1 0

Re: [mpich-discuss] Problem with SystemStubs under Mac OS X 10.7.5.
by Douglas Dommermuth 23 Feb '13

23 Feb '13

Hello Dave, I have attached the files that you requested (files.tar.gz). I could not find this file: mpich-3.0.2/src/pm/hydra/tools/topo/hwloc/hwloc/config.log. The output for compling pi3f90.f90 is below: mpif90 pi3f90.f90 ld: library not found for -lSystemStubs Thank you, Doug. [dgd]% tar -cvf files.tar files a files a files/.DS_Store a files/c.txt a files/config.log a files/m.txt a files/mi.txt a files/mpl a files/openpa a files/pm a files/pm/.DS_Store a files/pm/hydra a files/pm/hydra/.DS_Store a files/pm/hydra/config.log a files/pm/hydra/tools a files/pm/hydra/tools/.DS_Store a files/pm/hydra/tools/topo a files/pm/hydra/tools/topo/.DS_Store a files/pm/hydra/tools/topo/hwloc a files/pm/hydra/tools/topo/hwloc/.DS_Store a files/pm/hydra/tools/topo/hwloc/hwloc a files/openpa/config.log a files/mpl/config.log [dgd]% gzip files.tar On Feb 23, 2013, at 8:58 AM, Dave Goodell wrote: > On Feb 23, 2013, at 10:53 AM CST, Douglas Dommermuth wrote: > >> I am having trouble compiling a F90 code using mpif90. I get the following error: >> >> ld: library not found for -lSystemStubs >> >> I am running Mac OS X 10.7.5, which is highest OS that I can put on my Mac Pro Dual-Core Intel Xeon. I am using intel icc version 13.0.1 and intel ifort version 13.0.1. I am using Xcode version 4.6. I am using MPICH 3.0.2. Here are the first few lines of c.txt: > > […] > > The information you have included is insufficient to diagnose the problem. Please send all of the information listed in the README (c.txt, m.txt, etc.) as attachments. Also please include the output from attempting to compile "examples/f90/pi3f90.f90", together with the command you used to attempt to compile it. > > -Dave > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Problem with SystemStubs under Mac OS X 10.7.5.
by Dave Goodell 23 Feb '13

23 Feb '13

On Feb 23, 2013, at 10:53 AM CST, Douglas Dommermuth wrote: > I am having trouble compiling a F90 code using mpif90. I get the following error: > > ld: library not found for -lSystemStubs > > I am running Mac OS X 10.7.5, which is highest OS that I can put on my Mac Pro Dual-Core Intel Xeon. I am using intel icc version 13.0.1 and intel ifort version 13.0.1. I am using Xcode version 4.6. I am using MPICH 3.0.2. Here are the first few lines of c.txt: […] The information you have included is insufficient to diagnose the problem. Please send all of the information listed in the README (c.txt, m.txt, etc.) as attachments. Also please include the output from attempting to compile "examples/f90/pi3f90.f90", together with the command you used to attempt to compile it. -Dave

1 0

Problem with SystemStubs under Mac OS X 10.7.5.
by Douglas Dommermuth 23 Feb '13

23 Feb '13

Hello, I am having trouble compiling a F90 code using mpif90. I get the following error: ld: library not found for -lSystemStubs I am running Mac OS X 10.7.5, which is highest OS that I can put on my Mac Pro Dual-Core Intel Xeon. I am using intel icc version 13.0.1 and intel ifort version 13.0.1. I am using Xcode version 4.6. I am using MPICH 3.0.2. Here are the first few lines of c.txt: Configuring MPICH version 3.0.2 with '--prefix=/Users/dougdommermuth/mpich2/mpich-install' 'CC=/usr/bin/icc' 'FC=/usr/bin/ifort' Running on system: Darwin Macintosh-2.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:26:45 PDT 2012; root:xnu-1699.32.7~1/RELEASE_I386 i386 checking whether the C compiler works... yes Any suggestions on how to fix this problem? Thank you, Doug.

1 0

Re: [mpich-discuss] MPI_WIN_LOCK and MPI_MODE_NOCHECK assert
by Dave Goodell 23 Feb '13

23 Feb '13

Nightly tarballs are available here: http://www.mpich.org/static/tarballs/nightly/master/ In particular, this tarball should contain the change that Jim mentioned: http://www.mpich.org/static/tarballs/nightly/master/mpich-master-v3.0.2-54-… -Dave On Feb 22, 2013, at 4:39 PM CST, Jim Dinan wrote: > Hi Jaric, > > I pushed out the MODE_NOCHECK changes as a part of 9e68dcf86. Feel free to try them out. > > Best, > ~Jim. > > On 2/21/13 9:20 AM, Jim Dinan wrote: >> Hi Jaric, >> >> In current and previous releases of MPICH, MPI_MODE_NOCHECK was only >> used to optimize active target communication. As part of the MPI-3 >> work, we've also added a MPI_MODE_NOCHECK optimization to passive target >> communication. This feature should hopefully make it out to our git >> repo this week and be included in the in the next release. >> >> MPI_MODE_NOCHECK essentially asserts that the epoch can begin >> immediately at the target. If you are using exclusive locks, this means >> that the lock is uncontended. If you are using shared locks, this means >> that the lock is uncontended, or that all other processes are also using >> shared lock. >> >> In terms of the implementation for passive target, MODE_NOCHECK allows >> us to piggyback the lock request on the first RMA operation, since the >> user has asserted that the lock request will succeed immediately. >> >> Best, >> ~Jim. >> >> On 2/20/13 9:11 PM, Jaroslaw Zola wrote: >>> I have a question regarding implementation of the MPI_MODE_NOCHECK >>> assertion >>> for MPI_WIN_LOCK. Is current mpich implementation taking advantage of >>> this >>> hint? Also, according to the standard: >>> >>> MPI_MODE_NOCHECK - no other process holds, or will attempt to acquire, >>> a conflicting lock, while the caller holds the window lock. This is >>> useful when >>> mutual exclusion is achieved by other means, but the coherence >>> operations that >>> may be attached to the lock and unlock calls are still required. >>> >>> Are two concurrent locks from two different MPI processes followed by >>> MPI_GET >>> (i.e. given window is not modified but read only) considered conflicting? >>> >>> Thanks! >>> >>> - Jaric >>> >>> >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] stupid question about release names
by Dave Goodell 23 Feb '13

23 Feb '13

What are you looking at? SVN? Git? The downloads directory on the web? (the last one is my guess) 1.5 was the last release of MPICH2. You have correctly decoded the numbering scheme. Is there a reason you want MPICH2-1.5 instead of MPICH-3.0.2? The latter should be almost strictly better... -Dave On Feb 22, 2013, at 1:11 PM CST, Jeff Hammond wrote: > I'm sorry for being a moron, but I cannot figure out which of these is > the most recent release of the 1.5 branch: > > 1.5/ 20-Nov-2012 15:48 - > 1.5a1/ 20-Nov-2012 15:52 - > 1.5a2/ 20-Nov-2012 15:52 - > 1.5b1/ 20-Nov-2012 15:54 - > 1.5b2/ 20-Nov-2012 15:54 - > 1.5rc1/ 23-Nov-2012 08:36 - > 1.5rc2/ 20-Nov-2012 15:56 - > 1.5rc3/ 20-Nov-2012 15:57 > > I had hoped to use the time-stamp but that doesn't seem to help so > much. Is a=alpha, b=beta, rc=release candidate and therefore "1.5" is > the latest? And if there was a p=patch, that would be newer than > "1.5"? > > Again, I know this is a dumb question. Thanks for your tolerance. > > Best, > > Jeff > > -- > Jeff Hammond > Argonne Leadership Computing Facility > University of Chicago Computation Institute > jhammond(a)alcf.anl.gov / (630) 252-5381 > http://www.linkedin.com/in/jeffhammond > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI_WIN_LOCK and MPI_MODE_NOCHECK assert
by Jim Dinan 22 Feb '13

22 Feb '13

Hi Jaric, I pushed out the MODE_NOCHECK changes as a part of 9e68dcf86. Feel free to try them out. Best, ~Jim. On 2/21/13 9:20 AM, Jim Dinan wrote: > Hi Jaric, > > In current and previous releases of MPICH, MPI_MODE_NOCHECK was only > used to optimize active target communication. As part of the MPI-3 > work, we've also added a MPI_MODE_NOCHECK optimization to passive target > communication. This feature should hopefully make it out to our git > repo this week and be included in the in the next release. > > MPI_MODE_NOCHECK essentially asserts that the epoch can begin > immediately at the target. If you are using exclusive locks, this means > that the lock is uncontended. If you are using shared locks, this means > that the lock is uncontended, or that all other processes are also using > shared lock. > > In terms of the implementation for passive target, MODE_NOCHECK allows > us to piggyback the lock request on the first RMA operation, since the > user has asserted that the lock request will succeed immediately. > > Best, > ~Jim. > > On 2/20/13 9:11 PM, Jaroslaw Zola wrote: >> I have a question regarding implementation of the MPI_MODE_NOCHECK >> assertion >> for MPI_WIN_LOCK. Is current mpich implementation taking advantage of >> this >> hint? Also, according to the standard: >> >> MPI_MODE_NOCHECK - no other process holds, or will attempt to acquire, >> a conflicting lock, while the caller holds the window lock. This is >> useful when >> mutual exclusion is achieved by other means, but the coherence >> operations that >> may be attached to the lock and unlock calls are still required. >> >> Are two concurrent locks from two different MPI processes followed by >> MPI_GET >> (i.e. given window is not modified but read only) considered conflicting? >> >> Thanks! >> >> - Jaric >> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0