itaps-parallel Asynchronous functions in parallel interface

[Tim Tautges]

Conclusion:

After discussing after Lori hung up, we concluded that:
1) Asynchronous calls are still needed and useful for iMeshP, for 
various reasons.
2) We should document the fact that although some amount of work can be 
done after the asynchronous iMeshP call returns, there may be a 
non-negligible amount of work that needs to be completed synchronously 
(i.e. after the application calls a wait or test iMeshP function).

- tim


Onkar Sahni wrote:
> I do not think this is true that "asynchronous calls are really
> synchronous", that is irrespective of the (below mentioned) ways it is
> handled either by OS-level parts of MPI or mesh-library-level threads (I
> do not think any forking is necessary at iMesh level by implementations,
> one may choose to do that way but many parallel systems do not allow
> forking like IBM BG/L, Cray XT3 and I think its limited on IBM BG/P).
> 
> What MPI does and how it interacts with OS should not dictate the way we
> provide functionality.
> 
> On Jason's proposal, I do not recall discussion on this (I may have missed
> it) and I do not really see a reason why two tags (source and destination)
> are needed.
> 
> We can discuss more details on it via emails but before detailed email
> discussions I would instead recommend to schedule a phone conference to
> discuss these issues (if others think it is required).
> 
> - Onkar
> 
>> Hi all,
>>    Thinking more about Jason's proposal lead me to a really important
>> question about our parallel interface.  If we're proposing to have
> asynchronous functions like iMeshP_migrateEntity which return a request
> handle, with the application calling the test or wait functions to test
> whether a request has finished, where is the code which is executing
> that request running?  In the case of MPI, there is presumably some
> interaction with the OS, which is acting autonomously to fill buffers,
> transfer them to other processors, etc.  On large parallel systems
> that's handled by the OS-level parts of MPI; on workstations or
>> clusters, that's probably done by some other thread or process running
> on each node (or asynchronous calls are really synchronous).  For imesh,
> though, are any of the implementations able to do that kind of forking?
>>   I know MOAB never will.  In that case, I think asynchronous calls to
>> iMeshP don't make sense, or they only make sense if they're just
> pass-through functions to MPI, in which case they're superfluous.  I
> think it's down in the implementation where asynchronicity is used.  For
> example, when exchanging tags of owned entities, that function can
> initiate and wait for multiple asynchronous messages.  Comments?
>> - tim
>>
>> --
>> ================================================================ "You
> will keep in perfect peace him whose mind is
>>    steadfast, because he trusts in you."               Isaiah 26:3
>>
>>               Tim Tautges            Argonne National Laboratory
>>           (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
> phone: (608) 263-8485      1500 Engineering Dr.
>>             fax: (608) 263-4499      Madison, WI 53706
>>
>>
> 
> 
> 
> 
> 

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706