Electronic Transimission to gcf@indiana.edu strongly preferred Referees Home Page: http://aspen.ucs.indiana.edu/CandCPandE/ Email gcf@indiana.edu for URL of full paper to be reviewed WILEY Journal Home Page John Wiley and Sons, Ltd. Baffins Lane, Chichester West Sussex, PO19 1UD, England Telephone: (01243) 779777 Fax: (01243) 770379 REFEREE'S REPORT Concurrency and Computation:Practice and Experience ********** A: General Information Please return to: Geoffrey C. Fox Electronically Preferred gcf@indiana.edu Concurrency and Computation: Practice and Experience Computer Science Department 228 Lindley Hall Bloomington Indiana 47405 Office Phone 8128567977(Lab), 8128553788(CS) but best is cell phone 3152546387 FAX 8128567972 Please fill in Summary Conclusions (Sec. C) and details as appropriate in Secs. D, E and F. B: Refereeing Philosophy We encourage a broad range of readers and contributors. Please judge papers on their technical merit and separate comments on this from those on style and approach. Keep in mind the strong practical orientation that we are trying to give the journal. Note that the forms attached provide separate paper for comments that you wish only the editor to see and those that both the editor and author receive. Your identity will of course not be revealed to the author. C: Paper and Referee Metadata Paper Number Cnnn: C577 Date: 11/21/01 Paper Title: A comparison of concurrent programming and cooperative multithreading Author(s): Aaron W. Keen, Takashi Ishihara, Justin T. Maris, Tiejun Li, Eugene F. Fodor, and Ronald A. Olsson Referee: Henri Casanova Address: UCSD, Dept. 0114 9500 Gilman Dr. LA JOLLA, CA 92093-0114 Referee Recommendations. Please indicate overall recommendations here, and details in following sections. accepted provided changes suggested are made D: Referee Comments (For Editor Only) E: Referee Comments (For Author and Editor) This paper is very well written, interesting to read, and provides a large number of experimental results. The authors provide adequate discussion of their results. I am providing here detailed comments on several points that I think could be made clearer. Section 2: I think that the section should contain some qualitative discussion of why one model is more "user-friendly" than the other. I think that Figure 2 does not make enough of a point and that the text could develop a little more on the fact that explicit yields are more complicated. Maybe a more complex example would do. And the text misses some explicit statement about which model is less intuitive or attractive to developers. This brings me to a general comment about the paper. The abstract foreshadows a trade-off between "complicated code" and "performance", which makes sense. However, throughout the paper, the concern is mostly performance. In fact, the only place where programming styles are mentioned is in Section 6 (an 8 line paragraph on page 24). I would have liked to see more mention of that trade-off during the description of experimental results, if only to remind the reader why all this is worth the trouble. Section 3.1: I would maybe rename that section "Key CP Implementation Issues" as it is entirely about the CP programming paradigm. Section 3.2.1 and 3.2.2: I felt that those two sections were a little difficult to read. After spending quite a lot of time analyzing them I believe they are correct. I think that maybe a table or a paragraph describing the use of locks for each strategy for each platform would be good. As in: "SR_ic on single processor: no locking; SR_ts on single processor: a simple locked flag, etc.". That way the reader can just refer to that table for following the development rather than referring to section 3.1 constantly while reading the paper. Section 5: I think that this section should explicitly contrast the results with those of the previous section for SR. There are so many results in Section 4 that the reader needs a reminder to see how the Java results are different/similar to the SR results. Section 6: This section should really start with a summary of results. Throughout the paper the reader finds out facts such as: "SR_{IC} is good when there is a lot of synchronization", "SR_{IC} is bad when there is little work", etc.. I suggest you go through Sections 4 and 5, find all such statements and summarize the trends at the beginning of Section 6. My experience reading the paper was that I kept going back and forth between sections to remind myself of previous results and reasons for the results. I believe everything is there, but a summary is necessary. Maybe a section right before Section 6 called 'Summary of results and trends' would be good. Or maybe at the end of Section 4 and Section 5. I realize that some trends are not as clear cut as one would hope, but I still think that the authors can provide a coherent summary. F: Presentation Changes The presentation of the experiemtns and results is really good and the paper is extremely well-written. Besides my comments above I do not have further comments.