[saga-rg] BOUNCE saga-rg at ggf.org: Non-member submission from ["Rosa M. Badia" <rosab at ac.upc.edu>] (fwd)

Shantenu Jha s.jha at ucl.ac.uk
Wed Jan 19 08:40:08 CST 2005


To: Tom Goodale <goodale at cct.lsu.edu>
Cc: saga-rg at ggf.org, "Josep M. Perez Cancer" <perez at ac.upc.edu>
Subject: Re: [saga-rg] Asynchronous calls

Hi everyone,

sorry for answering so late, but I hope better late than never.

We agree with you. Option B is the best for us, given that is enough
flexible, generic and simple. However, we are curious about the C API
(for example, with GAT to copy a file from one location to another the
C program is almost two pages - probably this will generate some
discussion :-)).

The option that we like less is F, because it is not very flexible and
too sequential. However, it looks like the one that will fit better in
a C API. 

In general we see options A and E suited for object oriented APIs ,
but that it has not been thought how will affect in non-object oriented
programming languages. 

In any case, we can use C++, and if an API in C++ exists at some moment
we will be able to use it without much trouble.

Hope this can help.

Best regards, 

Rosa


On Fri, Jan 07, 2005 at 04:02:32PM -0600, Tom Goodale wrote:
> 
> Hi,
> 
> we'll shortly be circulating some strawman APIs from December's design 
> team meeting.  One issue which we would like some good feedback on is the 
> subject of asynchronous calls.  Currently we have an API with no 
> callbacks, but even so we came up with six possible ways to make the API 
> asynchronous, which are annotated below.  The first five involve the 
> generation of a task object, which would have as a minumum API
> 
>    task.run
>    task.wait(timeout)
>    task.cancel
> 
> and the last one (model F) is a straight async model where each call has 
> an asynchronous version.  The advantage of a task model over that is that 
> it allows more than one asynchronous operation on an object at one time.
> 
> The general feeling of the design team was that model B was the one to go 
> for, and that is the one currently being written up, however we would like 
> to get some more feedback on whether there are strong objections or if we 
> have missed anything crucial which would make this model unviable in 
> practice.
> 
> Cheers,
> 
> Tom
> 
> Note that the calls below are schematic, e.g. copy, move, signal, ... will 
> take more arguments.
> 
>   -----------------------------
>   SAGA_Directory dir = new SAGA_Directory ("foo://bar/baz")
>   SAGA_Job       job = ...
> 
>   -----------------------------
>   Model A)
> 
>   SAGA_DirTask dt1 = dir.createTask ();
>   SAGA_DirTask dt2 = dir.createTask ();
>   SAGA_DirTask dt3 = dir.createTask ();
>   SAGA_JobTask jt1 = job.createTask ();
>   SAGA_JobTask jt2 = job.createTask ();
> 
>   dt1.ls         ();
>   dt2.copy       ();
>   dt3.move       ();
>   jt1.checkpoint ();
>   jt2.signal     ();
> 
>   dt1.run ();
>   dt2.run ();
>   dt3.run ();
>   jt1.run ();
>   jt2.run ();
> 
>   -----------------------------
>   Model B)
> 
>   dtf = dir.createTaskFactory ();
>   jtf = job.createTaskFactory ();
> 
>   SAGA_Task t1 = dtf.ls         ();
>   SAGA_Task t2 = dtf.copy       ();
>   SAGA_Task t3 = dtf.move       ();
>   SAGA_Task t4 = jtf.checkpoint ();
>   SAGA_Task t5 = jtf.signal     ();
> 
>   t1.run ();
>   t2.run ();
>   t3.run ();
>   t4.run ();
>   t5.run ();
> 
>   -----------------------------
>   Model C)
> 
>   SAGA_Task t1 = dir.task.ls         ();
>   SAGA_Task t2 = dir.task.copy       ();
>   SAGA_Task t3 = dir.task.move       ();
>   SAGA_Task t4 = job.task.checkpoint ();
>   SAGA_Task t5 = job.task.signal     ();
> 
>   t1.run ();
>   t2.run ();
>   t3.run ();
>   t4.run ();
>   t5.run ();
> 
>   -----------------------------
>   Model D)
> 
>   SAGA_Task t1 = dir.task_ls         ();
>   SAGA_Task t2 = dir.task_copy       ();
>   SAGA_Task t3 = dir.task_move       ();
>   SAGA_Task t4 = job.task_checkpoint ();
>   SAGA_Task t5 = job.task_signal     ();
> 
>   t1.run ();
>   t2.run ();
>   t3.run ();
>   t4.run ();
>   t5.run ();
> 
>   -----------------------------
>   Model E)
> 
>   SAGA_Task t1 = dir.getTask ("ls");
>   SAGA_Task t2 = dir.getTask ("copy");
>   SAGA_Task t3 = dir.getTask ("move");
>   SAGA_Task t4 = job.getTask ("checkpoint");
>   SAGA_Task t5 = job.getTask ("signal");
> 
>   t1.run ();
>   t2.run ();
>   t3.run ();
>   t4.run ();
>   t5.run ();
> 
>   -----------------------------
>   Model F)
> 
>   (Not a "task" model)
>   dir.async_ls         ();
>   job.async_checkpoint ();
>   job.wait             ();
>   dir.wait             ();
>   dir.async_copy       ();
>   dir.wait             ();
>   dir.async_move       ();
>   job.async_signal     (URS);
>   job.wait             ();
>   dir.wait             ();

-- 

------------------------------------------------------------------------

				Rosa M. Badia 
				CEPBA-IBM Research Institute
				Dept. Computer Architecture
				Universitat Politecnica Catalunya
				Campus Nord - Modul D6
				c/Jordi Girona 1-3
				E08034 - Barcelona

				http://personals.ac.upc.edu/rosab/

				Tel. +34 - 934017191
				Fax: +34 - 934017055
------------------------------------------------------------------------






More information about the saga-rg mailing list