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

For corporate legal information go to:

Reply via email to