[saga-rg] tasks and jobs...

[G.E.POUND at soton.ac.uk]

Andre,

I have a couple of reservations about this action that you may be able to
answer.

I had been hoping to avoid implementing the 'Task' namespace in the java
bindings and encourage developers to use the language's support to
threading to allow asynchronous method calls in the client code.

I am therefore concerned about creating a dependency between the
'JobManagement' namespace and the 'Task' namespace.

The submission of remote jobs is naturally asynchronous, and there are
natural semantic parallels to the asynchronous model described by the
'Task' namespace. However from my reading of the API I understood these two
models to be independent in purpose; creating a dependency could hinder the
natural description (and development) of these two areas of the API.

The idea of a job container for the management of a large number of remote
jobs is useful. However the TaskContainter does not appear to be wholly
compatible; the run() method to start the asynchronous operations is
unnecessary for jobs that have been submitted to a remote resource.

Graeme


Quoting Andre Merzky <andre at merzky.net>:

> Hi,
>
> I just had a discussion with Thilo about the topic, as he
> and me obviously talked somewhat orthogonal to each other...
>
> Well, now we have the same opinion, kind of, and I have
> barely any bruises...  Anyway, I want to summarize our point
> here, as I probably was not really clear in my initial post.
>
> Sorry if re-iteration of the topic bores you...
>
> So, we have tasks, which represent async operations, with a
> couple of states attached, and the ability to call run(),
> wait() and cancel() on these.  And we can collect them in
> containers, and wait() on many of these tasks conveniently.
>
> And then we have jobs, which represent remote executables,
> with a couple of states attached, and the ability to call
> run (== create them), wait() and cancel().  And some more
> methods.  And we can't collect them in containers right now,
> but would like to.
>
> You see the similarities, right?  Its even more obvious in
> code:
>
>   Tasks:
>   --------------------------------------------
>     task_container tc;
>     task t = file.copy <saga::task> (...);
>          t.run  (   );
>          t.wait (1.0);
>
>         tc.add  (t);
>         tc.wait ( );
>   --------------------------------------------
>
>   Jobs:
>   --------------------------------------------
>     job_container jc;
>     job j = job_server.submit (job_descr);
>         j.wait (1.0);
>
>        jc.add  (j);
>        jc.wait ( );
>   --------------------------------------------
>
>   slightly changed:
>   --------------------------------------------
>     job_container jc;
>   ! job j = job_server.create (job_descr);
>   +     j.run  (   );
>         j.wait (1.0);
>
>        jc.add  (j);
>        jc.wait ( );
>   --------------------------------------------
>
> The similarities are obvious I think.  Now, if job would
> IMPLEMENT the task interface (or inherit from task), we
> would unify both classes, and hence:
>
>   - simplify jobs (leave only those methods which are
>     specific to jobs, like migrate, signal, ...
>
>   - allow to out jobs into task containers, efficiently
>     handling large amounts of jobs and other tasks
>
>   - have the API and used paradigms more uniform.
>
> Also, if later tasks get suspendable, as Gregor rightly
> suggested, we can move more methods to tasks, w/o breaking
> the paradigms.
>
> In terms of state, following mappings would be appropriate:
>
>   job::Pending -> task::Pending
>   job::Done    -> task::Done
>   job::Failed  -> task::Failed
>   job::???     -> task::Cancelled
>
>   job::Queued,Running,Pre/Poststaging,... -> task::Running
>
> So, no adjustements to the statet models are needed AFAICS,
> apart from Cancelled
> (Does it make sense   on jobs?
>  Should job::stop     be job::cancel?
>  Should tasks::cancel be task::job?)
>
> Hope that clearifies things.  I think Gregor was on target
> with his remarks, and Hartmut signalled consent as well.
> And I think I convinced Thilo (Andre rubs his bruises).
>
> Unless there is any opposition, I'll go ahead and document
> that in the strawman then, ok?
>
> Cheers, Andre.
>
>
> Quoting [Thilo Kielmann] (Feb 04 2006):
> > Date: Sat, 4 Feb 2006 22:29:41 +0100
> > From: Thilo Kielmann <kielmann at cs.vu.nl>
> > To: saga-rg at ggf.org
> > Subject: Re: [saga-rg] tasks and jobs...
> >
> > > Wouldn't it be useful to have jobs implementing the task
> > > interface?
> >
> > Certainly, no.
> > Jobs and Tasks are two different things, and they are this on purpose.
> >
> > However, Tasks always have been the mechanism for asynchronous
> operation,
> > which is kind-of obsoleted by having asynchronous ops directly.
> >
> > If you want to work on the "S" of SAGA: why not unify both Tasks and
> Jobs
> > into a better "Job" notion, and do local asynchronous operations via
> > async, local calls?
> >
> > Thilo
> --
> "So much time, so little to do..."  -- Garfield
>
>
>
>