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

[Thilo Kielmann]

Dear Andre and Pascal, dear all on the list,

we seem to have different opinions on the proper handling of shared objects
and of concurrency control. I had been silent as I did not see a way how to
resolve this. First of all, we all should separate our own opinions from our
own work, favourite language, and implementations...

I think there are a few facts that we need to accept:

1. SAGA is about simplicity of use. Application programmers should require
   only a minimum of additional mental burden to use SAGA.

2. The SAGA spec MUST be independent of all possible implementation languages.
   The spec should allow language bindings that make SAGA-Java to "feel like"
   normal Java programming, SAGA-C++ to feel like normal C++ programming, and
   SAGA-Fortran to feel like normal Fortran programming...
   Along the same line, a SAGA binding to C++ must not require using a library 
   like boost, or equivalent.

3. With the task model, SAGA has introduced a concurrent programming model.


The recent discussion on the list has been revolving around:
a) object lifecycle (and memory) management
b) concurrency control
c) being prescriptive or leaving freedom to the application programmer

In previous mails, I have argued for some amount of being presriptive.
By now, I think, we should give up being presciptive all together, paving
the road for both simplicity and flexibility for application programmers.
(This will have a price to pay, though, see below.)

And here comes my suggestion what to do with with a) and b):

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.

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. 

   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. 



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