[saga-rg] SAGA thread model

[Andre Merzky]

Hi Thilo, 



Quoting [Thilo Kielmann] (Jul 17 2006):
> 
> I am sorry to say, but SAGA's task model seems to me severely flawed.
> This is for two reasons:
>
> 1. the "main" thread (executing sync operations) 
>    needs to be considered as yet another task

In what respect?  In respect to object state that is the
case.  Did you have something else in mind?


> 2. there must be a concise definition of the shared state. current solutions
>    are ad-hoc and mostly undefined.

Why do you think that?  We might need to better express that
in the doc, but the current solution is "object state is
shared".  That is not really ad-hoc, and its well defined.

So, what exactly do you think needs better definition?


>    shared state is:
>      - local objects, shared between multiple tasks of the same process
>        here: definition of synchronization between tasks

What does synchronization between tasks mean?  As tasks are
async, they are, by definition, not synchronized.

>      - remote objects, in the service(s)
>        here: definition of legal execution orders

We don't make assumptions about 'legal execution order' -
where would that order be defined?  It is application (i.e. use case) dependent IMHO.

Why should that order have an reflection in the API?  Do you
have an example?  I might miss the point here...


> so far, I can see only a few incidental definitions, but they are far from
> being concise.

Please have a look at the intro (CVS version).  I worked on
that over the last days, and tried to clarify these issues.  
Do they make sense to you?


> "tasks in a bulk operation have to be independent"

bulks are not mentioned in the spec.  I brought that as an
example only.  Should have left that out.


> "a task cancel is doing 'best effort' but can not guarantee cancelation"
>
> The latter, BTW, is a special case, because this is about connection 
> termination for which you can formally prove that there is no protocol that 
> can guarantee this AND notify both parties of successful termination.

Exactly.  So, so we agree that delayed deallocation of
resources for cancel and destructors makes sense, at least
in those cases?

That is described in the subsection "Freeing of Resources and
Garbage Collection" in the specs intro - can you check if
you agree with that?


> To be constructive:
> what the task model must do first thing is
> - define tasks

The definition in the spec is:

  "Objects of this class represent asynchronous API calls."

A task in saga is what RPC has as async rpc handle.  As the
SAGA spec is OO, calling it handle would be strange, but it
is in fact not much more than that.


> - define which data is shared between tasks and which concurrency control
>   happens on this shared data

All is shared, no control.


> That is the only way to define clearly what tasks will do in the event of
> sharing, really.
> 
> You may want to look at:
> 
> http://www.amazon.com/gp/product/0201695812/qid=1153102128/sr=2-3/ref=pd_bbs_b_2_3/002-2045221-3597631?s=books&v=glance&n=283155
> 
> This is: 
> Doug Lea, "Concurrent Programming in Java: Design Principles and Patterns"
> 
> This book uses 280 pages on objects, shared state and concurrency control
> before using 95 pages for the thread operations...

I had a look through a number of other specifications a
while ago, about exactly these topics.  I must say that most
left me in the dark.  Some, as e.g. the MPI spec, moves the
responsibility for correct call order to the end user:

  "A correct, portable program must invoke collective
   communications so that deadlock will not occur, whether
   collective communications are synchronizing or not."

That is, in some sense, what we do as well: the order of
async ops is undefined, and its the end users responsibility
to sync them, if that is of any concern.

Corba protocol spec says:

  "Overlapping requests - In general, GIOP message ordering
  constraints are minimal.  GIOP is designed to allow
  overlapping asynchronous requests; it does not dictate the
  relative ordering of requests or replies."

and is otherwise silent about object state (well, as far as
I can say after skimming through the 1152 page monster...)

API Specs like Gnome and the GTK+ thingie does the same as
SAGA: allow async calls, and specify them, and leave
ordering and consistency to the end user.  Same for GridRPC
by the way.

Frankly, I don't see any other realisitic (== usable and
implementable) way.

Cheers, Andre.


-- 
"So much time, so little to do..."  -- Garfield