Scenario: You work as a developer in XYZ company. Your manager has tasked you to work on a project for one of your company’s clients based on their requirements.
Client Details and Requirements
Firm Name: U235 Nuclear Power Plant
Client Requirement:
We at U235 Nuclear Power Plant are very concerned about our employees’ well-being.
Considering the nature of work, we plan to give a wearable device to track our employees’ health and relay that information to a smartphone through an app.
Project Details
The device is ready, and the app development team will create the mobile app.
You are working in a team responsible for creating an OS (you are free to assume an OS) for the wearable device.
You have been assigned to do the following:
Choose the method your company’s device’s CPU uses process precedence, using the methods mentioned in the reading assignments.
Convey the rationale behind your choice by explaining in detail why you would use this particular method to the development team.
You will pitch to convince the team that your idea is the best method for the device to utilize.
Important Note: Keep in mind that there is not much information being processed other than relaying a lot of I/O to the smartphone and a display to the user.
The main problem is building an operating system for a wearable device that will be used to track the user’s health.
The device will be used by employees of a nuclear power plant for real-time monitoring of their health.
The device constantly checks the user’s vital signs and relays that information to the user’s smartphone App.
To summarize the tasks of the wearable device:
Receive the user’s vital signs (heart rate, blood pressure, etc.) from sensors: periodically issuing I/O requests to the sensors.
Process the received data and prepare it to be shipped (through the appropriate network protocol) to the smartphone App: internal processing.
Ship the data to the smartphone App: periodically issuing I/O requests to the network to send the data.
Display the received data on the device’s display: issue I/O requests to the display.
The device issues a lot of I/O requests in different directions but not doing complex calculations since that is going to be done on the smartphone App.
As discussed earlier, the device’s tasks are limited, and so are the processes running on the device.
Probably each process will be responsible for a single task, and each sensor will have its own process.
So the expected Processes to be running on the device are:
A Reader that issues I/O requests to the sensors (A process for each sensor); the more sensors, the more processes.
A Packetizer that processes the received data and prepares it to be shipped to the smartphone App. Depending on the network protocol’s complexity, the data’s size, and how often the data is sent, there may be more than one Packetizer process.
A network process that issues I/O requests to the network to send the data (also, there may be more than one).
A process that issues I/O requests to the display to display the received data.
Processes belonging to the OS itself (e.g., the process that runs the OS’s scheduler).
Processes belonging to drivers of sensors, networks, and display devices.
The simple approach uses a First Come, First Serve (FCFS) scheduling algorithm.
The data is time-sensitive; sending a later received data before an earlier received data will cause the smartphone App to display the data out of order.
It is crucial for the device to not delay the data it receives from the sensors and to respect the order of the data as received.
This approach is simple, easy to implement, and preserves the order of the data as received, but it is not perfect.
Some of the drawbacks that may arise from using this approach:
Workers are busy. When they need to check the device in hand, the device (through the display) must respond immediately and not queue their requests behind some less critical requests.
Most of the processes listed above are I/O bound. I/O requests tend to take time to complete, and during this time, the CPU remains idle, so this approach may not be ideal for CPU utilization.
Some processes may not be strictly time-sensitive; for example, the network process can queue some of its packets and send them a few milliseconds later as long as the order is preserved.
The better approach uses a Priority Scheduling algorithm.
The OS can create different queues with different priority levels; However, the scheduling algorithm for each queue is First Come, First Serve (FCFS).
When a process is created, it is assigned a priority level, and the OS adds it to the appropriate queue.
The OS will pick the processes from the highest priority queue and run them using the FCFS algorithm.
Once the highest priority queue is empty, the OS will pick the next queue and run its processes using the FCFS algorithm.
While waiting for an I/O request, the process will be returned to the same queue, and another process from the same queue will be picked to run.
While waiting for an I/O request, the OS will not pick another process from the lower priority queue if the queue only has one process. Instead, it should wait for the process to finish.
OS should categorize the processes into the following queues:
High Priority: Includes processes that are time-sensitive and must be executed immediately. Examples include user requests through the display and the reader processes.
Medium Priority: Includes processes that are not time-sensitive but must be executed as soon as possible. Examples include the packetizer.
Low Priority: Includes processes that are not time-sensitive and can be executed later. Examples include the network process.
The text included two approaches to solving the problem. There are better solutions, and many more factors affect the chosen approach. These factors start with the teams’ experience and do not end with the project’s budget, but the text focuses on the approaches mentioned in the reading assignments.
Priority scheduling solves many issues faced in the FCFS approach; it maximizes interactivity with the user and the CPU utilization; while preserving the time ordering of the data.
Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. (2018). Operating systems: three easy pieces (1.01 ed.). Arpaci-Dusseau Books. Retrieved June 16, 2022, from https://pages.cs.wisc.edu/~remzi/OSTEP/.