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

[Thilo Kielmann]

Hoho,

I think you understand...

> 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'?

please excuse my ignorance, you mean someting like the following?

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

Then f is getting out of scope and will be destroyed by the C++ runtime system.
That's fine, a "means of the programming language".

Does your agreement also imply you agree that this is obsoleting sections
1.3.7 Life Time Management
and 
1.3.8 Freeing of Resources and Garbage Collection
of the current "strawman" spec?

> > 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.

It never was about re-inventing. The alternative would be prescribing to use
such mechanisms.

> 
> 
> >    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'.

Disagree. This would again prescribe the use of thread-safe implementations.
So you would enforce the overhead of thread-safety (e.g. locking all over the
place) also to Fortran ???
Really, "we don't prescibe anything" also excludes prescribing thread safety.

Keep it for the language binding. That's where it belongs.


Thilo
-- 
Thilo Kielmann                                 http://www.cs.vu.nl/~kielmann/