Hi Thilo,
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.
Agreed 100%
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...
Agreed as well.
Along the same line, a SAGA binding to C++ must not require using a library like boost, or equivalent.
Strongly disagree. 1. Boost is nothing else than the C++ Standards library of tomorrow. In fact about 10 of Boosts libraries are accepted in C++ TR1 or TR2 already. More to follow. 2. The Boost libraries are peer reviewed and nowadays used by half of the C++ community. The code quality and portability is much more better than everybody could easily craft. If we were not using Boost we'ld have to write all this code ourselfs - which doesn't make any sense to me. 3. You are talking about keeping this discussion free from any language specifics, but OTOH you're trying to push through a requirement, which is highly language specific.
3. With the task model, SAGA has introduced a concurrent programming model.
Agreed.
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
Since you've started the C++ business youself here, I'll try to answer your questions wrt the C++ implementation we have so far.
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.
That's exactly the way it is in the C++ ref implementation we have so far.
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.
That's exactly the way it is in the C++ ref implementation we have so far, with the exception, that SAGA protects internal data structures to avoid internal race conditions.
The application programmer is free to use separate concurrency control mechanisms from his/her own programming environment, like mutexes, semaphors, monitors, locks, etc.
IIUC, this mainly means, that the SAGA implementations should not prevent to use the application programmer whatever concurency model/library he wants to use. I don't see anyproblems here, since all the concurency handling introduced by an implementation is internal to this implementation anyways (at least as long this implementation is crafted in a sensible way).
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 with your observations. Regards Hartmut
Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/