[saga-rg] SAGA, object states, and concurrency
Thilo Kielmann
kielmann at cs.vu.nl
Mon Jul 31 22:13:39 CDT 2006
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/
More information about the saga-rg
mailing list