Operating System Kernel

VRML World for VRML World
Image Gallery
Author: John Hopkins
Overview: This world is not only a visualization of a program. It IS the program. The program in question is a generic operating system (O/S) kernel task scheduler (utilizing a dynamic priority queueing system) that moves tasks from one resource to another inside the computer. The following acronyms are used: CPU (Central Processing Unit), DEV (External Device), COM (Communications such as via the parallel, serial and USB ports), MEM (Memory), and I/O (input/output channels). Tasks (expressed as people) move from a holding room on the left (Void) toward the CPU and then gain access to one of 5 O/S resources. From there they head back to the CPU for more processing. When a task/person leaves the "void" (on the left of the world), it has been "randomly" assigned a task type (e.g., cpu, dev, com, mem, or i/o). "Random" is quoted because the user has some control over the probability that each specific task type will be chosen. The randomization of task fields is performed centrally by an instance of RANDOMIZER stationed inside the void. The RANDOMIZER has no geometry, so it cannot be seen inside the world. The randomizer simply takes tasks in, assigns their fields, and spits them back out. The user, in fact, is changing randomizer probabilities with the Heads Up Display (HUD) controls. The randomizer starts out with a 50/50 mix of cpu vs. other device probabilities, which the user then alters. The intial weights are such: cpu - 20, dev - 5, com - 5, mem - 5, io - 5. No control is given over cpu weight because the HUD is already cluttered and changing the weights of the devices uniformly is equivalent to changing the weight of cpu tasks. If the task is a cpu task, it is also randomly assigned a cpu service time that the cpu will need to dispatch that task. The randomness of cpu task service time, however, is determined by fields in the RANDOMIZER declaration, so the user has no control over it from the browser. If the task is something other than a cpu task, it is assigned a service time of zero (that is, the cpu will send it on its way to the appropriate device immediately upon arrival at the cpu). All tasks start out with a priority of 1 upon leaving the void. When a task leaves the void, it enters the first priority queue to the cpu. When the task reaches the cpu, if the task is not a cpu task, it is sent along to the appropriate device. What happens at the devices will be described shortly. If the task *is* a cpu task, it gets service from the cpu. The cpu determines how much time to spend servicing the task as follows: Priority 1 tasks are given 10 seconds, which is the priority 1 time quantum. If this quantum is expended before the total service time for the task is complete, the cpu assigns the task a priority of 2, updates the remaining total service time for that task, and sends it to the second priority queue. The other priority queues work the same way, except their cpu time quantums are 20, 30, and 40 for priorities 2, 3, and 4 respectively. If a task reaches priority 4, goes to the cpu, expends the 40 second time quantum, and is still not finished executing, the cpu leaves the task at priority 4 and sends it back to the fourth priority queue. When a cpu task's total service time is expended, it is sent back to the void. Time quantums for each priority are determined by the CPUFACILITY declaration. The cpu decides which queue to draw tasks from based on the following rule: it draws a task from the highest priority queue that has a *waiting* task (by *waiting*, the task is meant to be at the head of the queue, not traveling/in transit from the end of the queue to the head). Lower priority queues may starve, but this is a danger of any priority queueing system that is not implemented in a round-robin fashion (i.e., the cpu samples each queue successively: first one, then two (even if there are waiting tasks in queue 1), etc. If a queue is empty, the cpu samples the next, and finally wraps around to the first queue again). Round-robin would be easy enough to implement if so desired. When a non-cpu task arrives at its device, the device decides on a random service time for that task. When this time is expended, the task is sent back to the void. There is no priority queueing at the devices - these queues are pure FIFO. The random service time at the devices is determined by fields in the FACILITY declarations. All queues are managed by instances of the QUEUEMANAGER proto, which send out waiting tasks upon request from the cpu and devices. Person/tasks have internal accounting abilities - they are individuals, and maintain their own task type, remaining run time, and priority information, which are utilized especially by the RANDOMIZER and CPUFACILITY.
Model Templates: QNET= Queuing Network.
Metaphors: People as programs or tasks to be executed; Floor Paths as traces taken from one resource to another; Office workers as controllers of major O/S resources.
Simulation: Viewpoints: Initial, CPU, DEV, COM, MEM, I/O, Void. Execution: press Execute to start the model (queuing network)-- simulation stays on for duration until world is reloaded. One starts outside the multi-story building and then zooms into one room in this building where the program takes place. Animation: avatars move toward the CPU and then off to be serviced by one of CPU, DEV, COM, MEM or I/O. The HUD allows for adjustment of the weight used to determine the mean time spent in these services. Audio: CPU : backbeat; DEV: church bell; COM: wind; MEM: flowing water; I/O: raindrops and thunder.
Modeling PROTOs used: WORLD; FRONTPANEL (Heads Up Display); MFACTORY (Token generator); PATH(Token paths and animation); PERSON (Token fileds and geometry model); QUEUEMANAGER (all queues); CPUFACILITY (the CPU); FACILITY (Services, e.g.: DEV, COM, MEM, I/O); RANDOMIZER (randomization of Token fields).

Object Hierarchy: Format is Object (PROTO); PROTOs are all uppercase in parentheses; field names are in italics; field values are to the right of field names.

HUD (FRONTPANEL)

  panelObjects ExecuteButton, PathButton, DEVUPButton, DEVDOWNButton, COMUPButton, COMDOWNButton, MEMUPButton, MEMDOWNButton, IOUPButton, IODOWNButton

FacilityWorld (WORLD)

  contains Hotel, Stairway Shaft, Bottom Floor, Middle Floor, Facility Room, Source, Traces, CPU, DEV, COM, MEM, IO

Source (MFACTORY)

  howMany 10

  interval 1.07

  vizMode 0

  viz PERSON

Paths (PATH)

  origin, destination, rug, visibility multiple values

CPU (CPUFACILITY)

  service_time_quantum_p1 10

  service_time_quantum_p2 20 

  service_time_quantum_p3 30  

  service_time_quantum_p4 40

DEV (FACILITY)

  min_random_service_time 45

  max_random_service_time 90

COM (FACILITY)

  min_random_service_time 45

  max_random_service_time 90

MEM (FACILITY)

  min_random_service_time 45

  max_random_service_time 90

IO (FACILITY)

  min_random_service_time 55

  max_random_service_time 110

RAND (RANDOMIZER)

  cpu_min_run_time 9

  cpu_max_run_time 120