C: Paper and Referee Metadata 

     Paper Number Cnnn: C515
     Date: 26 June 2001
     Paper Title: A Parallel Algorithm for Static Slicing of Concurrent Programs
     Author(s): D. Goswami, R. Mall

     Referee: Fethi Rabhi

     Address: f.rabhi@unsw.edu.au

Referee Recommendations. Please indicate overall recommendations here, and details in
following sections.

   2.accepted provided changes suggested are made 

D: Referee Comments (For Editor Only) 

This is a well conducted study, supported by a theoretical setting and practical
experiments. My main concern is about the relevance of the study (see my first comment,
Section E.). From the references, it seems that there are people working in the area so why
not ? (this won't be the first time people keep reinventing the wheel). Perhaps you should
consider the opinion of the other referee on this before accepting the paper.

E: Referee Comments (For Author and Editor) 

This is a well conducted study on a parallel slicing algorithm for concurrent programs
operating in a Unix-like environment. The paper is well structured and mostly follows a
logical structure.

My main concern is about the originality and the relevance of the study. This problem has
been well studied in automatic parallelization (of Fortran for example) work in 80s.
Intermediate structures were called Directed Acyclic Graphs (DAGs) most of the time. It has
been established that parallelism obtained that way only gets you very modest performance
gains and the only way better performance can be achieved is in the presence of loops (not
tackled by the authors) for which a large body of literature exists. Experiments reported
in your paper show a 50% efficiency for 4 processors so it confirms that claim. However,
the results of the study seem to work well in a specific context and it is detailed in a
way that can be implement so the paper has definitely practical value.

There are also some problems in the way the paper is structured. I have had problems
understanding Section 2 because too many concepts in it are only introduced much later
(CFG, RCFG, etc.) so it should be removed or placed much later. Also, the work reported in
the paper is an extension of previous work reported as reference [4]. It is not very clear
where the new contribution of this paper is in relation to the other one.

F: Presentation Changes 

General: there is a need for consistency in the way graphs are named. Sometimes you use
abbreviations (CFG, RCFG), sometimes a full name (process graph, concurrency graph). It is
best to stick to one way.

-page 1: "at distributed location" -> "at distributed locations"

-page 6: "can handle only" -> "can only handle"

-page 12: "Wesier" -> "Weiser"

-page 13: difficult to understand what the slicing criterion <P,s,V> is until page 17 so it
is best to do some rearranging here.

-page 13: "as Weiser slice" -> "as  a Weiser slice"

-page 13: "we extend the parallel algorithm proposed in [5]" : explain what was that
original algorithm proposed for.

-page 15: "Behavior of each" -> "The behavior of each"

-page 17: "process behavior already discussed" -> "already discussed process behavior"

-page 21: "then submit to the Scheduler" -> "then submit them to the Scheduler"

-page 21: "8 sample programs" -> how are them characterized ? beside their length, how many
independent threads of computations do they contain ?