[saga-rg] Re: SAGA, object states, and concurrency

[Andre Merzky]

Hiho, 

Quoting [Thilo Kielmann] (Aug 01 2006):
> 
> a) SAGA does NOT handle object life cycle and memory management at all.
>    It is ALWAYS the responsibility of the application programmer to create
>    and destroy objects, even if objects are created via SAGA constructors.
>    SAGA thus NEVER destroys objects. (with the exception of data structures
>    that are internal to its implementation, that are not exported/visible
>    at the API) The application programmer has to do object creation and
>    destruction, with the respective means of the programming language in use.

I am not sure I understand the proposal (a) really.  Please
don't take my questions not as criticism, it's really about
clarifying what you mean.  And sorry for the examples beeing
C++ :-)

If you say that the application programmer MUST destroy
objects explicitely, that would mean that the code:

  {
    saga::file (url);
    file.copy  (tgt);
  }

would leak memory?  File goes out of scope, but as the
instance is not explicitely destroyed by the programmer (no
file.destroy() called or whatever), the object stays active?
Or would you include 'going out of scope' into the 'means of
the programming language'?


> b) SAGA does NOT impose any concurrency control mechanisms. It is the
>    responsibility of the application programmer to ensure the correctness of
>    his/her program. In case of SAGA's tasks, the application programmer has
>    to make sure that all tasks and the main program execute correctly, in
>    any possible interleavings or execution orders. Whenever tasks share objects
>    with each other or the main program, the application programmer must
>    ensure that no race conditions will occur.
> 
>    The application programmer is free to use separate concurrency control 
>    mechanisms from his/her own programming environment, like mutexes,
>    semaphors, monitors, locks, etc. 

I agree to (b) so far, totally.  These separate control
mechanisms are aviable and not Grid specific - so there is
no need for SAGA to re-invent them.


>    The related problem of thread-safety for SAGA operations is not
>    applicable on the level of the SAGA specification. It has to be addressed
>    on the level of language bindings. 

I agree to that to some extend - the spec should, IMHO,
limit itself to the statement 'SAGA implementations MUST be
thread safe'.

Cheers, Andre.

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