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

[Hartmut Kaiser]

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/
>