Referee 1 ****************************************************************

E:Referee Comments(For Author and Editor)

This paper presented a lock-free scheduling implementation of Lesser Bear for SMP.

It would be more interesting if the paper also had proof that the algorithm used in
the implementation is also deadlock/livelock free.

F:Presentation Changes

1) There are many grammatical mistake and typos.

2) Please eliminate the repetition of "no lock operations".

Referee 2 ****************************************************************

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 not be published in current form, 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.