Written documentation for section "The Schedulables/Requests tree"

git-svn-id: svn://svn.gna.org/svn/sgpemv2/trunk@1074 3ecf2c5c-341e-0410-92b4-d18e462d057c
This commit is contained in:
elvez 2006-09-08 23:18:56 +00:00
parent 5825423f79
commit c0b65e96e9
1 changed files with 49 additions and 4 deletions

View File

@ -89,6 +89,8 @@ Free Documentation License''.
@unnumbered History @unnumbered History
@table @strong @table @strong
@item 2006, September 9th @r{--- Luca Vezzaro}
Written documentation for section "The Schedulables/Requests tree"
@item 2006, September 8th @r{--- Luca Vezzaro} @item 2006, September 8th @r{--- Luca Vezzaro}
Written documentation for section "Overall view of the main window" Written documentation for section "Overall view of the main window"
@item 2006, September 8th @r{--- Matteo Settenvini} @item 2006, September 8th @r{--- Matteo Settenvini}
@ -564,14 +566,14 @@ Normally, the window is split into three sections.
@itemize @itemize
@item @item
The top left section is briefly called The top left section is briefly called
the "Schedulables tree", although this is not completely correct, since except from resources, the "Schedulables tree", every entity, except resources, in the SGPEMv2 is shown and
every entity in the SGPEMv2 is shown and edited in this tree view. edited in this tree view.
The interface of this widget is straightforward, but in case you need to know about it, The interface of this widget is straightforward, but in case you need to know more about it,
see @ref{The Schedulables/Requests tree}. see @ref{The Schedulables/Requests tree}.
@item @item
The top right section is the resources list, you can interact with it in the same way you do The top right section is the resources list, you can interact with it in the same way you do
with the Schedulables tree. We won't get into the details here, as there is with the Schedulables tree. We won't get into the details here, as there is
@ref{The Resources list, a dedicated section} for this widget. @ref{The Resources list, a dedicated section} for this widget.
@item @item
@ -590,6 +592,49 @@ need it if you don't use resources and/or requests in your simulation. For more
@subsection The Schedulables/Requests tree @subsection The Schedulables/Requests tree
@cindex schedulables tree @cindex schedulables tree
This widget is used to add/edit/remove processes, threads and requests.
To perform an operation on it, simply right-click, and a context-sensitive menu
will popup.
Each tree level is dedicated to a specific entity:
@itemize
@item The first level is for @strong{processes}
@item The second level is for @strong{threads}
@item The third level is for @strong{requests}
@end itemize
Right-clicking on any location over the tree will always allow you to add processes, while to
add threads or requests you must select a process or a thread, respectively.
To remove or edit an entity simply select it, and the popup menu will contain the remove
or edit operation specific for that entity.
Anyway, these functionalities are only useful for a stopped simulation. While the simulation
is not in a stopped state, a lot of dynamic information is displayed by the widget.
Let's begin by describing what's the meaning of the colors used to highlight the entities' name:
@itemize
@item @strong{Light Grey} is used for "future" processes, threads, requests and subrequests.
"future" means an entity in the real world will still not exist, since it will "arrive"
at a time greater than the current instant
@item @strong{Green} is used for running processes, threads and for allocated requests and subrequests
@item @strong{Yellow} is used for ready processes, threads and for allocable requests and subrequests
@item @strong{Red} is used for blocked processes, threads and for unallocable requests and subrequests
@item @strong{Dark Grey} is used for terminated processes, threads and for exhausted requests and subrequests
@end itemize
The dynamic display for processes and threads simply consists of their "elapsed time" (the time they've
been given the processor) and "current priority", which is obviously their dynamic priority which may change
if the scheduling policy decides to do so.
Probably the format used to display requests is a bit less trivial (yes, I'm sarcastic), but since
a request has no additional information other than its state, it makes sense to condense requests and
its associated subrequests on a single line. @*
So the color of the @strong{at <n>:} represents the state of the
request, the <n> being the instant at which the request is raised.@*
Then there are a series of subrequests, which are displayed as colored @strong{->} (arrows), followed by a
resource name and two numbers separated by a slash. The color of the arrow represents the state of the subrequest,
and the numbers between parenthesis are its "elapsed time"/"required time".
@c % ------------------------------------------------- @c % -------------------------------------------------
@node The Resources list, The Simulation widget, The Schedulables/Requests tree, From the GUI @node The Resources list, The Simulation widget, The Schedulables/Requests tree, From the GUI
@subsection The Resources list @subsection The Resources list