Concurrent Task Scheduling Simulation in Java

by andyterra
macOS ◆ xterm-256color ◆ zsh 28 views

Consider a computer and operating system that is available 24 hours/7 days a week (provided no disasters). The physical system that is to be simulated has eight processors that are manage by operating system threads that execute user tasks on behalf of the user (IE. Each processor thread receives a message from the user task to complete the current execution tasks). The operating system has a long-term scheduler that admits user tasks (threads) to the system to then be serviced by two short term schedulers. Each of the two short term schedulers has access to four processors and has an associated shared queue by the four operating system threads that perform the execution (four threads will manage the execution of the user tasks on those simulated processors).

User tasks simulated with a unique thread each enter the system at random times throughout the system lifecycle entering the long term scheduler queue. A user task cannot enter one of the short term scheduler queues if each is filled to capacity (the short term schedulers have a max limit of 15 active tasks). If the there is an open slot in a short term scheduler queue a user task will gain access to a short term scheduler queue and thus compete for processor service with the other tasks in that short term queue. Each user task will enter the system with a specific amount of time slices necessary to complete the user task (each user task will have a random time slice requirement of one to 25 Units).

As soon as a processor thread is free, the user task in that short term scheduler queue that has the shortest remaining time to compete their total units of execution is processed next by a specific processor thread (the user thread must exit the short term scheduler queue and move to the specific processor area to receive the processor thread execution service). A processor thread is either executing a user task or waiting on the next available user task. Each processor thread will have a specific time quantum to provide execution service (processor 1: two units; processor 2: four units; processor 3: three units; and processor 4: two units). In the event that a user’s entire execution requirements have not been completed on the current execution cycle by the processor thread the user thread must reenter the short term scheduler associated with processor thread they just received execution units on. Each of the two short term scheduler queues is organized by the shortest remaining execution time algorithm. When a user’s entire execution requirements are completed, the user task and associated thread leave the system.

More by andyterra

untitled 00:31

by andyterra

FlushQL 01:33

by andyterra

See all