This paper surveys 3 components of a real-time operating system: task
scheduling, protocol processing and disk scheduling.  Overall the paper is
well written and clearly organized.  However the paper is inconsistent in
its expectations of the readers background and occasionally assumes the
reader is well informed about issues in a real-time operating system.  This
is most apparent in section 3 which is difficult to understand without a
strong background in real-time systems.

======================================================================

This paper discussed an interesting topic and explained it thoroughly and 
clearly (as well as possible in only 10 pages). The topic was focused 
enough to fit comfortably within the page limit but still cover the 
material well. The layout was easy to read, figures were incorporated into 
the paper smoothly, and the writing was well done. Scheduling is a key 
feature of RT systems and they explained the material and importance of the 
topic clearly. There were some sections where terms were used without being 
defined, though generally the authors understood and matched the audience's 
expected level of knowledge. The paper looks professionally laid out, is 
generally easy to read, and covers the topic material well. Section 3 
didn't flow well with the rest of the paper well though, and could use some 
more editing. Overall I was quite impressed by this paper.

======================================================================

This paper focuses on Real-time operating systems and in particular
observes task scheduling algorithms, protocol processing, and disk
scheduling. For each of these cases, different approaches are presented as
well as the recent work based on these approaches or the combination of
those. The comparisons are provided nicely as well. The only downside
parts of the paper are that some parts are covered too complicated and
confusing and no new idea is offered other than the future directions
stated.

======================================================================


1. First thing that comes NO ABSTRACT!!!!! How does a reader know what they 
are trying to do??

2. The title sounds like they are talking of Real time
system resources. CPU and Device I/O come to mind. BUT
they have talked about Protocol processing, Disk scheduling
etc which are specific to COmmunicatin RT, Multimedia systems etc.
They should have had a more suitable title.

3. They have used many terms without prior explanation or definitions. e.g.
Schedulability analysis, Admission control, QoS Negotiation which they have 
assumed the reader is well versed with.

4. All through the paper, the authors have used ambiguous and non-technical 
terms that dont convey what they are trying to say.
e.g. "... throw away more important tasks ..." Does this mean the tasks are 
never scheduled/considered again?
"... first task to appear in the scheduler " What does appear mean?
" Static user priorities are left to the user" Does this imply assigned by 
the user ?


5. Some statements are not justified. e.g. "THis strategy is well understood 
and contributes to wide popularity" -
A reasonable thing to say provided there are backing statistics  may be - 
This seems to be a popular strategy, based on stats and therefore seems to 
have been an appreciated one.


"This does not take much effort for implementation.IT can be easily 
implemented by ..." A reasonable thing to say would have been - This may 
facilitate relatively simpler imlementation.
Specially when this an implementation strategy suggested with no practical 
verification.

6. Suggestions for future research are not very novel and are reasonably 
obvious
e.g. " Fault tolerance in Real time systems needs attention", "scheduling 
algorithms in Multimedia systems need to be developed for a tradeoff between 
quality and timeliness" These are fairly obvious.


7. The quality of criticism is a little weak. The have not clearly marked 
out their inferences since they get mixed up with some obvious results which 
have also been mentioned.
e.g. "Threads need to interact synchronously in the face of pre-emption and 
context switches ; locking data structures ...
This leads to run-time overhead and ensuing reduction in utilization" It is 
reasonably intuitive to figure out the overheads.

======================================================================