SAM public review comment -- Pro

rdv at ISI.EDU rdv at ISI.EDU
Fri Apr 14 15:32:47 PDT 1995

   >Page 72, section 8.6.2:  This example (HEAD OF QUEUE tasks) is very
   >1.  It isn't obvious why a group of simple tasks have an Ordered
   >Blocking Boundary between them (between task 2 and task 4).  I think
   >this is because when task 3 is accepted then subsequent simple tasks
   >are dormant until all head or queue tasks complete.  It might help the
   >example to show this since anybody who understands why the Ordered
   >Blocking Boundary is present at the start probably doesn't need the

   Comment accepted. Rather than modify the existing example, I propose that a new
   example be created to show how an HOQ task creates the ordered blocking
   boundary which partitions the task set.

I, too was confused by this. As the tasks are numbered in the order
received, though, I think even a simple text modification might solve
the problem. Change note 1 to read:

1) Head of Queue task 3, received as a Head of Queue task, is in the
enabled state. Simple tasks 1 and 2, received and already enabled when
Head of Queue task 3 was received, remain enabled. Tasks 4,5 and 6 are
dormant, as they were received after Head of Queue task 3, and
therefore must wait for it to end.


This is a little long, and does have the disadvantage of describing
state 1 in terms of actions rather than its static state; perhaps
you're right that another head of queue example would help.

Perhaps if you entered 3 and 7 into the _bottom_ of the set of enabled
tasks, rather than the _top_, it would be a little clearer that it
simply expedites joining the set of enabled tasks.

One other objection I have to the state diagrams is that you show
transitions such as "task 2 ended, task 7 created" and "tasks 7, 4 and
6 ended". This implies that a single state change can represent
changes to multiple tasks, when in truth this is a _series_ of state


More information about the T10 mailing list