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