January 2005 - saga-rg - lists.ogf.org

SAGA Design Team meeting today
by Shantenu Jha 31 Jan '05

31 Jan '05

Reminder: The second phase of the SAGA Design Team meeting begins today. For those who are attending via Access Grid, we will be using the LBNL institutional venue. Please contact Lloyd Belknap at ag(a)lbl.gov to tell him you are participating. We are currently seeing numerous multicast problems on ESNet, so be prepared to use a bridge. Lloyd will start setting things up at 8am (PST). https://agschedule.ncsa.uiuc.edu:443/meetingdetails.asp?MID=7392 Rough Agenda (by John Shalf): Day 1 (Jan 31): Editing: It appears we still have some work to do in order to make the strawmen consistent with one-another before we compile them into a single coherent document. I propose we spend day one walking through the documents one-by-one to critique the current contents. I know there are some people with concerns about the overall direction of the group, but this first day is strictly concerned with editing & form issues. Function is part of day #2. We will go over the following strawmen in order Files Logical Files Namespaces Streams Attributes Tasks The focus of Day 1 is to get the text part of the strawman proposal complete. Day 2 (Feb 1): From 9am-10am, we will briefly review any changes that were implemented from the day1 meeting. This will be followed immediately by a Blood-letting session. There are some concerned voiced about the overall direction the RG has taken in construction of the strawman. This is the part of the meeting where those concerns should be discussed. This includes specific problems that people can identify with the strawman API's and more general issues with the overall target of the APIs and whether they meet the goals set forth in the group's charter. The members of this group (particularly the leaders) need to be prepared to stand up and answer hard questions about the strawmen & the group's direction at the GGF13 meeting in Seoul. Therefore, it is best to get all of the hardest, most difficult questions out in the open *before* getting on stage trying to explain what is going on. Day 3 (Feb 2): Just as the LSU workshop, the agenda for the last day will become readily apparent during the course of the first two days. Some likely candidates are * continuation of blood-letting * discussion of some of the issues that cut across multiple APIs. These issues include Error Handling, Attributes & Namespaces, callback/event handling, and security. We tabled these issues in the last meeting, but we are all well aware that these capabilities need to be managed uniformly across the APIs. * Final strawman document assembly.

1 0

BOUNCE saga-rg@ggf.org: Non-member submission from ["Rosa M. Badia" <rosab@ac.upc.edu>] (fwd)
by Shantenu Jha 19 Jan '05

19 Jan '05

To: Tom Goodale <goodale(a)cct.lsu.edu> Cc: saga-rg(a)ggf.org, "Josep M. Perez Cancer" <perez(a)ac.upc.edu> Subject: Re: [saga-rg] Asynchronous calls Hi everyone, sorry for answering so late, but I hope better late than never. We agree with you. Option B is the best for us, given that is enough flexible, generic and simple. However, we are curious about the C API (for example, with GAT to copy a file from one location to another the C program is almost two pages - probably this will generate some discussion :-)). The option that we like less is F, because it is not very flexible and too sequential. However, it looks like the one that will fit better in a C API. In general we see options A and E suited for object oriented APIs , but that it has not been thought how will affect in non-object oriented programming languages. In any case, we can use C++, and if an API in C++ exists at some moment we will be able to use it without much trouble. Hope this can help. Best regards, Rosa On Fri, Jan 07, 2005 at 04:02:32PM -0600, Tom Goodale wrote: > > Hi, > > we'll shortly be circulating some strawman APIs from December's design > team meeting. One issue which we would like some good feedback on is the > subject of asynchronous calls. Currently we have an API with no > callbacks, but even so we came up with six possible ways to make the API > asynchronous, which are annotated below. The first five involve the > generation of a task object, which would have as a minumum API > > task.run > task.wait(timeout) > task.cancel > > and the last one (model F) is a straight async model where each call has > an asynchronous version. The advantage of a task model over that is that > it allows more than one asynchronous operation on an object at one time. > > The general feeling of the design team was that model B was the one to go > for, and that is the one currently being written up, however we would like > to get some more feedback on whether there are strong objections or if we > have missed anything crucial which would make this model unviable in > practice. > > Cheers, > > Tom > > Note that the calls below are schematic, e.g. copy, move, signal, ... will > take more arguments. > > ----------------------------- > SAGA_Directory dir = new SAGA_Directory ("foo://bar/baz") > SAGA_Job job = ... > > ----------------------------- > Model A) > > SAGA_DirTask dt1 = dir.createTask (); > SAGA_DirTask dt2 = dir.createTask (); > SAGA_DirTask dt3 = dir.createTask (); > SAGA_JobTask jt1 = job.createTask (); > SAGA_JobTask jt2 = job.createTask (); > > dt1.ls (); > dt2.copy (); > dt3.move (); > jt1.checkpoint (); > jt2.signal (); > > dt1.run (); > dt2.run (); > dt3.run (); > jt1.run (); > jt2.run (); > > ----------------------------- > Model B) > > dtf = dir.createTaskFactory (); > jtf = job.createTaskFactory (); > > SAGA_Task t1 = dtf.ls (); > SAGA_Task t2 = dtf.copy (); > SAGA_Task t3 = dtf.move (); > SAGA_Task t4 = jtf.checkpoint (); > SAGA_Task t5 = jtf.signal (); > > t1.run (); > t2.run (); > t3.run (); > t4.run (); > t5.run (); > > ----------------------------- > Model C) > > SAGA_Task t1 = dir.task.ls (); > SAGA_Task t2 = dir.task.copy (); > SAGA_Task t3 = dir.task.move (); > SAGA_Task t4 = job.task.checkpoint (); > SAGA_Task t5 = job.task.signal (); > > t1.run (); > t2.run (); > t3.run (); > t4.run (); > t5.run (); > > ----------------------------- > Model D) > > SAGA_Task t1 = dir.task_ls (); > SAGA_Task t2 = dir.task_copy (); > SAGA_Task t3 = dir.task_move (); > SAGA_Task t4 = job.task_checkpoint (); > SAGA_Task t5 = job.task_signal (); > > t1.run (); > t2.run (); > t3.run (); > t4.run (); > t5.run (); > > ----------------------------- > Model E) > > SAGA_Task t1 = dir.getTask ("ls"); > SAGA_Task t2 = dir.getTask ("copy"); > SAGA_Task t3 = dir.getTask ("move"); > SAGA_Task t4 = job.getTask ("checkpoint"); > SAGA_Task t5 = job.getTask ("signal"); > > t1.run (); > t2.run (); > t3.run (); > t4.run (); > t5.run (); > > ----------------------------- > Model F) > > (Not a "task" model) > dir.async_ls (); > job.async_checkpoint (); > job.wait (); > dir.wait (); > dir.async_copy (); > dir.wait (); > dir.async_move (); > job.async_signal (URS); > job.wait (); > dir.wait (); -- ------------------------------------------------------------------------ Rosa M. Badia CEPBA-IBM Research Institute Dept. Computer Architecture Universitat Politecnica Catalunya Campus Nord - Modul D6 c/Jordi Girona 1-3 E08034 - Barcelona http://personals.ac.upc.edu/rosab/ Tel. +34 - 934017191 Fax: +34 - 934017055 ------------------------------------------------------------------------

1 0

SAGA-WG Meeting Reminder
by John Shalf 18 Jan '05

18 Jan '05

Hi everyone. the SAGA workshop on "Strawman APIs" will continue at Berkeley Jan 31-Feb 3. The meeting will also be available via Access Grid in the LBNL Institutional Venue. https://agschedule.ncsa.uiuc.edu:443/meetingdetails.asp?MID=7392 Local participants can find maps and directions to Berkeley Lab at http://www.lbl.gov/Workplace/Transportation.html The "Hotel Shattuck" is one block from the LBNL bus route and from BART. Rooms are $79/night. http://www.hotelshattuckplaza.com/ Thus far, Christopher Smith and Shantu Jha have indicated they will be attending on site. Please tell me soon if anyone else will be coming to Berkeley to attend. For the rest of you, I'll see you on the AG. -john

1 0

Asynchronous calls
by Tom Goodale 07 Jan '05

07 Jan '05

Hi, we'll shortly be circulating some strawman APIs from December's design team meeting. One issue which we would like some good feedback on is the subject of asynchronous calls. Currently we have an API with no callbacks, but even so we came up with six possible ways to make the API asynchronous, which are annotated below. The first five involve the generation of a task object, which would have as a minumum API task.run task.wait(timeout) task.cancel and the last one (model F) is a straight async model where each call has an asynchronous version. The advantage of a task model over that is that it allows more than one asynchronous operation on an object at one time. The general feeling of the design team was that model B was the one to go for, and that is the one currently being written up, however we would like to get some more feedback on whether there are strong objections or if we have missed anything crucial which would make this model unviable in practice. Cheers, Tom Note that the calls below are schematic, e.g. copy, move, signal, ... will take more arguments. ----------------------------- SAGA_Directory dir = new SAGA_Directory ("foo://bar/baz") SAGA_Job job = ... ----------------------------- Model A) SAGA_DirTask dt1 = dir.createTask (); SAGA_DirTask dt2 = dir.createTask (); SAGA_DirTask dt3 = dir.createTask (); SAGA_JobTask jt1 = job.createTask (); SAGA_JobTask jt2 = job.createTask (); dt1.ls (); dt2.copy (); dt3.move (); jt1.checkpoint (); jt2.signal (); dt1.run (); dt2.run (); dt3.run (); jt1.run (); jt2.run (); ----------------------------- Model B) dtf = dir.createTaskFactory (); jtf = job.createTaskFactory (); SAGA_Task t1 = dtf.ls (); SAGA_Task t2 = dtf.copy (); SAGA_Task t3 = dtf.move (); SAGA_Task t4 = jtf.checkpoint (); SAGA_Task t5 = jtf.signal (); t1.run (); t2.run (); t3.run (); t4.run (); t5.run (); ----------------------------- Model C) SAGA_Task t1 = dir.task.ls (); SAGA_Task t2 = dir.task.copy (); SAGA_Task t3 = dir.task.move (); SAGA_Task t4 = job.task.checkpoint (); SAGA_Task t5 = job.task.signal (); t1.run (); t2.run (); t3.run (); t4.run (); t5.run (); ----------------------------- Model D) SAGA_Task t1 = dir.task_ls (); SAGA_Task t2 = dir.task_copy (); SAGA_Task t3 = dir.task_move (); SAGA_Task t4 = job.task_checkpoint (); SAGA_Task t5 = job.task_signal (); t1.run (); t2.run (); t3.run (); t4.run (); t5.run (); ----------------------------- Model E) SAGA_Task t1 = dir.getTask ("ls"); SAGA_Task t2 = dir.getTask ("copy"); SAGA_Task t3 = dir.getTask ("move"); SAGA_Task t4 = job.getTask ("checkpoint"); SAGA_Task t5 = job.getTask ("signal"); t1.run (); t2.run (); t3.run (); t4.run (); t5.run (); ----------------------------- Model F) (Not a "task" model) dir.async_ls (); job.async_checkpoint (); job.wait (); dir.wait (); dir.async_copy (); dir.wait (); dir.async_move (); job.async_signal (URS); job.wait (); dir.wait ();

1 0