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/