[saga-rg] Task model...

[Pascal Kleijer]

Hello Andre,


Andre Merzky wrote:
> Hi Pascal, 
> 
> Quoting [Pascal Kleijer] (Nov 11 2005):
>> Hello,
>>
>> If you are working on a C++ model why work with flags? Simply use the 
>> power of the language and use inheritance. A core abstract class give 
>> the general common stuff and then you can derivate as wished to a 
>> synchronous and asynchronous class.
>>
>> In that case the calls can remain the same but the behavior changes:
>>
>> saga::directory d= new SynchronousDirectory()
>> or
>> saga::directory d= new AsynchronousDirectory()
>>
>>
>> std::list<string> l;
>> saga::task t = d.list(&l);
>> t.wait();
>> do something with l
>>
>> In the synchronous case the list is filled up and in the asynchronous 
>> case the list will be filled only after the task has properly ended. 
>> Calling the wait on the sync task will directly return.
> 
> What about our example of doing a sync seek, then a async
> write on a file?
> 
>   saga::file f1 = new saga::SyncFile  (url);
>   saga::file f2 = new saga::AsyncFile (url);
>   
>   f1.seek (100, SEEK_CUR);
>   saga::task t = f2.read (100, buffer);
> 
> f2 still stands on the 0 position.  So you can't mix sync
> and async calls on a object in that way.  Also, your sync
> calls do return a task (probably finished), not an error
> code.  Well, that problem pops up in most proposals we have
> so far...

In a language as Java this wouldn't be a problem. Because each thread 
has its own handler. The URL and File are a just pointers (logical or 
physical) and not the handler itself. You will have to deal with 
streams, they are independent anyway so you could have 1000 threads 
reading the same file in different places. Of course if you do a write, 
you will have a system lock on the file so you won't be able to open 
more then one stream anyway.

You might face more difficulties with older languages like C to solve 
this issue.


>> So:
>> 1) You have uniformed calls.
>> 2) You can overwrite the class without affecting the definition.
>> 3) You can interchange the classes without touching your code.
> 
> Right, good points...
> 
> 
>> Having the sync flag set on the fly and change the behavior might be 
>> very difficult to handle in case of race conditions. I'm used to code 
>> multi-tasked applications that often share numerous objects and changing 
>>    the sync/async behavior will be a real problem if you don't take 
>> care. Debug that sort of code is hell.
> 
> Yes, agree.  Nobody really seems to like flags in terms of
> implementation.  But well, it looks simple on API level,
> that the appealing part...

Actually in implementation like in C, flags would probably be the 
options. This is more a language binding issue then an API definition issue.


> 
> Thanks, Andre.
> 
> 
>> my 2ct.
>>
>> 'Andre Merzky' wrote:
>>> Hmm, I thought so as well, you know.  But actually, error
>>> conditions are flagged by excptions, so we would not return
>>> errors anyway.  So it does not matter if e.g.  mkdir_sync ()
>>> returns a task: it would not be used anyway. (If the task
>>> gets returned it is Finished.  If it failes, an error is
>>> thrown.)
>>>
>>> OTOH, for calls which do return infos this is different:
>>> directory.ls ();  would normally return a list of strings  I
>>> guess.  With the proposed model, the list would need to be
>>> returned in I/O parameters, such as:
>>>
>>> std::list<string> l;
>>> d.ls_sync (&l);
>>>
>>> So, the problems are not error conditions, but return values
>>> I guess.  
>>>
>>> However, similar considerations hold for the other task
>>> models: at least the signature of the method calls might
>>> look different for synchroneous and asynchroneous calls:
>>>
>>>  sync in version B:
>>>
>>>    std::list<string> l = d.sync.ls ();
>>>
>>>  async in version B:
>>>  
>>>    std::list<string> l;
>>>    saga::task t = d.sync.ls (&l);
>>>
>>> I created some more verbose examples at 
>>>
>>>  http://wiki.cct.lsu.edu/saga/space/Task+Models
>>>
>>> (see bottom of page) -- I hope that helps the discussion.
>>> Feel free to change/edit/correct them, and in fact to edit
>>> that page.
>>>
>>> Again: the cuurent discussion does ONLY affect the C++
>>> language binding for now!
>>>
>>> Cheers, Andre.
>>>
>>>
>>>
>>> Quoting [Hartmut Kaiser] (Nov 08 2005):
>>>> The main question is, do we need to have different return values from
>>>> sync/async operations or not. It's kind of unusual to get a task from a
>>>> 'normal' sync operation, even more because this task is usable for return
>>>> value retrieval only.
>>>>
>>>> Regards Hartmut


-- 

Best regards,
Pascal Kleijer

----------------------------------------------------------------
   HPC Marketing Promotion Division, NEC Corporation
   1-10, Nisshin-cho, Fuchu, Tokyo, 183-8501, Japan.
   Tel: +81-(0)42/333.6389       Fax: +81-(0)42/333.6382