RE: Generalized Request Progress

[Anthony Skjellum <tony@xxxxxxxxxxx>]

Rajeev,

My strong recollection here is that there were no persistent generalized
requests, and this is what made them hard to use for other purposes too.

-Tony

On Thu, 30 Aug 2007, 
Rajeev Thakur wrote:

   Torsten,
           Interesting note! For this very reason we have proposed some
   extensions to the generalized request interface in a paper to be presented
   at Euro PVM/MPI next month. We face the same problem in implementing the
   MPI-IO nonblocking I/O functions using generalized requests. You can find
   the paper at www.mcs.anl.gov/~thakur/papers/grequest-redesign.pdf.
   
   Regards,
   Rajeev
   
   > -----Original Message-----
   > From: owner-mpi-21@xxxxxxxxxxxxx 
   > [mailto:owner-mpi-21@xxxxxxxxxxxxx] On Behalf Of Torsten Hoefler
   > Sent: Thursday, August 30, 2007 1:52 PM
   > To: mpi-21@xxxxxxxxxxxxx
   > Cc: lums@xxxxxxxxxxxxxx; dgregor@xxxxxxxxxxxxxx
   > Subject: Generalized Request Progress
   > 
   > Hello,
   > we (Douglas Gregor and me) tried to port LibNBC [1] to use MPI
   > generalized requests to enable MPI_Wait{all|some}() for a specific
   > application scenario. 
   > 
   > LibNBC uses an internal state machine to represent the stage 
   > (round) of
   > the collective operation. A progress function (in this case 
   > NBC_Test())
   > needs to be called to ensure internal progress (of the collective
   > operation). 
   > 
   > We realized that there is no way to ensure progress with generalized
   > requests (without threads) because there is no function that is called
   > everytime the user calls test or wait on the request (the query_fn is
   > only called after the request is finished). This seems to enforce a
   > threaded implementation of any non-blocking operation that uses
   > generalized requests. This scheme seems to be suboptimal in some
   > use-cases. First, not all parallel environments support threads (e.g.,
   > Catamount) and second, we show in [2] that, at least for some
   > applications, a non-threaded implementation may perform better than a
   > threaded implementation.
   > 
   > We would like to add some way to progress the operation 
   > without threads.
   > We consider this issue as a bug that renders the current interface
   > useless for several use-cases and it is easy to fix (thus, 
   > we'd like to
   > see a fix in MPI 2.1). The possible two fixes seem to be 
   > reasonable and
   > easy to implement:
   > 
   > 1) change the behavior of query_fn such as that it is called 
   > every time
   > when the associated request is tested or waited on (spinning 
   > in case of
   > wait) - this may be suboptimal, because it could break 
   > existing code and
   > changes the defined behavior
   > 
   > 2) add a new function "MPI_Grequest_start_progress(progress_fn,
   > query_fn, free_fn, cancel_fn, data, request)" that defines the passed
   > progress function to be called when the associated request is 
   > tested or
   > waited on.
   > 
   > Any comments? We are of course open for other suggestions and
   > discussions!
   > 
   > Thanks & Best,
   >   Torsten
   > 
   > [1]: http://www.unixer.de/research/nbcoll/libnbc/
   > [2]: T. Hoefler and P. Kambadur and R. L. Graham and G. Shipman and 
   >   A. Lumsdaine: A Case for Standard Non-Blocking Collective Operations
   >   (accepted for publication at the EuroPVM/MPI 2007)
   > 
   > -- 
   >  bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
   > Indiana University    | http://www.indiana.edu
   > Open Systems Lab      | http://osl.iu.edu/
   > 150 S. Woodlawn Ave.  | Bloomington, IN, 474045-7104 | USA
   > Lindley Hall Room 135 | +01 (812) 855-3608
   > 
   > 
   
   

Anthony Skjellum, PhD
Professor and Chair
Dept. of Computer and Information Sciences
University of Alabama at Birmingham
+1-(205)934-8657; FAX: +1-(205)934-5473
___________________________________________
CONFIDENTIALITY:  This e-mail and any attachments are confidential and
may be privileged.  If you are not a named recipient, please notify the
sender immediately and do not disclose the contents to another person,
use it for any purpose or store or copy the information in any medium.