On Feb 18, 2010, at 10:48 AM, Ethan Mallove wrote: > To ensure there is never a collision between $a->{k} and $b->{k}, the > user can have two MTT clients share a $scratch, but they cannot both > run the same INI section simultaneously. I setup my scheduler to run > batches of MPI get, MPI install, Test get, Test build, and Test run > sections in parallel with successor INI sections dependent on their > predecessor INI sections (e.g., [Test run: foo] only runs after [Test > build: foo] completes). The limitation stinks, but the current > limitation is much worse: two MTT clients can't even run the same > *phase* out of one $scratch.
Maybe it might be a little nicer just to protect the user from themselves -- if we ever detect a case where $a->{k} and $b->{k} both exist and are not the same value, dump out everything to a file and abort with an error message. This is clearly an erroneous situation, but running MTT in big parallel batches like this is a worthwhile-but-complicated endeavor, and some people are likely to get it wrong. So we should at least detect the situation and fail gracefully, rather than losing or corrupting results. Make sense? > I originally wanted the .dump files to be completely safe, but MTT > clients were getting locked out of the .dump files for way too long. > E.g., MTT::MPI::LoadInstalls happens very early in client/mtt, and an > hour could elapse before MTT::MPI::SaveInstalls is called in > Install.pm. Yep, if you lock from load->save, then that can definitely happen... -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/