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

[Andre Merzky]

and hi :-)


Quoting [Thilo Kielmann] (Aug 01 2006):
> > 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);
> }

yep, sorry...


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

ok, understand what you mean now.


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

Aehm, no ;-)  Now, here is the counterargument:

IO think what you propose works nicely, is simple, and is
well defined (simple rules).  However, I think its awkward
to use.

Our favourite bulk file copy code snippet would, for
example, cease to work:

-----------------------------------------------
  saga::task_container tc;

  for (i = 1; i < 1000; i++)
  {
    saga::file f (url[i]);
    saga::task t = f.copy <saga::Task> ("/tmp/");
    tc.add (t);
  }
  
  tc.run ();
  tc.wait ();
-----------------------------------------------

Its not only the file object which goes out of scope here,
its also the task!  

Also, it basically means that a programmer needs to keep
track of sessions!

-----------------------------------------------
// pseudo code
saga::session s;
saga::directory d(s, url);
saga::file f = d.open (name);
d.destroy ();
-----------------------------------------------

can/must session be destroyed here?  No, as it is still
needed by file.  The situation gets much worse with many
objects, and tasks, which are passed around in subroutines.
Effectively, the application programmer has to do reference
counting, and needs to know exactly where a session is
inherited, and where not.  

All that is simple to do in the SAGA implementation, which
_knows_ where it is inherited, and which will do ref
counting anyway...

Again, I think your proposal is simple and it works, so its
an valid option -- but IMHO it makes programming SAGA
applications an ugly business.

Nix f"ur ungut :-)

Cheers, Andre.




> 
> > > 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
-- 
"So much time, so little to do..."  -- Garfield