Subject: Re: Request to review a paper C524: Lesser Bear: a lightweight process library for SMP computers - scheduling mechanism without a lock operation From: Michael Oudshoorn Date: Mon, 17 Sep 2001 11:04:45 +0930 To: fox@csit.fsu.edu, gcf@indiana.edu X-UIDL: be8f8c57631d0000 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Received: by mailer.csit.fsu.edu (mbox gcfpc) (with Cubic Circle's cucipop (v1.31 1998/05/13) Sun Oct 14 21:43:58 2001) X-From_: fox@mailer.csit.fsu.edu Sun Oct 14 21:43:44 2001 Return-Path: Delivered-To: gcfpc@csit.fsu.edu Received: from dirac.csit.fsu.edu (dirac.csit.fsu.edu [144.174.128.44]) by mailer.csit.fsu.edu (Postfix) with ESMTP id 769B023A05 for ; Sun, 14 Oct 2001 21:43:39 -0400 (EDT) Received: from localhost by dirac.csit.fsu.edu (AIX4.2/UCB 8.7) id VAA86758; Sun, 14 Oct 2001 21:43:38 -0400 (EDT) Resent-Message-Id: <200110150143.VAA86758@dirac.csit.fsu.edu> Replied: Sun, 16 Sep 2001 21:44:57 -0400 Replied: Michael Oudshoorn Delivered-To: fox@csit.fsu.edu Received: from rosemary.cs.adelaide.edu.au (rosemary.cs.adelaide.edu.au [129.127.8.221]) by mailer.csit.fsu.edu (Postfix) with ESMTP id B10CC23A21 for ; Sun, 16 Sep 2001 21:34:15 -0400 (EDT) Received: from cs.adelaide.edu.au (courses-33.staff.cs.adelaide.edu.au [129.127.8.133]) by rosemary.cs.adelaide.edu.au (8.11.4/8.11.2/cs.nonhub/cjp.20000626) with ESMTP id f8H1YCY00146; Mon, 17 Sep 2001 11:04:13 +0930 (CST) Message-ID: <3BA55335.EFDC7EFE@cs.adelaide.edu.au> Organization: University of Adelaide X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3B847847.7000503@csit.fsu.edu> Content-Type: multipart/mixed; boundary="------------925C066E7EA2ACB8439D5291" Resent-To: Geoffrey Fox Resent-Date: Sun, 14 Oct 2001 21:43:33 -0400 Resent-From: Geoffrey Fox CandC:PandE Referee Report Form *********************************************** Electronic Transimission to gcf@indiana.edu strongly preferred Referees Home Page: http://aspen.csit.fsu.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: C524 Date: 17 September, 2001 Paper Title: LesserBear: a lightweight process library for SMP computers - scheduling mechanism without a lock operation Author(s): Hisashi Oguma & Yasuichi Nakayama Referee: Michael Oudshoorn Address: Department of Computer Science, University of Adelaide, Adelaide Australia Referee Recommendations. Please indicate overall recommendations here, and details in following sections. reject D: Referee Comments (For Editor Only) The English expression used in the paper makes it difficult to clearly understand and follow. A detailed example showing how it works would help overcome some of these difficulties. Even though I have recommended that the paper be rejected, I would like to see the authors encouraged to submit an improved and more detailed version of the paper. I believe that it makes a reasonable contribution (not huge) and, if delivered properly, would be worthy of journal publication. E: Referee Comments (For Author and Editor) In its current form the contribution of the paper appears relatively small. This views stems primarily from the way in which the information is presented - namely, the English usage and the lack of a clear worked example. The paper is confusing in some aspects - for example, the paper switches its focus between LesserBear1 and the current implementation (without locks) fairly regularly. It is made worse when the authors are talking about the current implementation and suddenly (and without warning) switch to the previous version and talk about locks! The discussion on page 2, and continuing throughout the paper, on "protect Queue" and "WaiverQueue" is unclear. I have no real idea of what the function or size of these queues is, not al I clear as to who to "owner" actually is and therefore who is entitled to enqueue and dequeue threads from these queues. I'm also confused about the remarks indicating that "anyone can dequeue from the WaiverQueue". I appreciate why this requires locks in the initial implementation but it appears that in order to avoid locks in the current implementation the authors do not allow "anyone" to dequeue - only the forward neighbour is permitted to do thin in the rotator scheduling mechanism proposed. If I am indeed correct in my understanding of the rotator scheduling mechanism , then the authors will need to make sure that the contribution of the paper is explicitly stated. This paper ends by providing some figures demonstrating the effectiveness of the new method. I think that it would be helpful if the code was presented. I think figure 6 needs to be expanded to show, step-by-step, how the thread was distributed and the load balanced across all available processors. F: Presentation Changes The clarity of English needs to be addressed. For example, text on page 2 and 3 had to be read several times before I thought I understood it, only to discover that I hadn't understood it properly when I reached later parts of the paper. An example showing, step-by-step, how the threads become evenly distributed as claimed in Figure 6, will aid clarity and be more convincing. Michael Oudshoorn Senior Lecturer University of Adelaide Department of Computer Science Michael Oudshoorn Senior Lecturer University of Adelaide Department of Computer Science Adelaide SA 5005 Australias Fax: +61 8303 4366 Work: +61 8 8303 4478 Additional Information: Last Name Oudshoorn First Name Michael Version 2.1