Embedded systems have the following characteristics:

Require small code size and can operate within limited storage space.

Application-oriented, can be cut and ported.

Used in specific fields, can support multitasking.

High reliability, timely response, can operate independently without human intervention.

High real-time performance, and requires solid-state storage.

Requires determinism and predictability before the system is put into operation.

Generally tested in multiple-choice questions.

BIT (Built-In Test) can complete fault detection and localization. It includes the following four types:

Power-On BIT: Self-test of all hardware resources when the system is powered on, having 100% CPU control.

Periodic BIT: Periodically tests hardware during idle time while the system is running, using non-destructive testing algorithms since the system is operational.

Maintenance BIT: Maintenance testing of all hardware resources under maintenance status, also having 100% CPU control.

Startup BIT: This startup does not mean system startup, but rather maintenance personnel manually starting BIT to check for hardware faults.

To be honest, before the soft exam, I didn’t know what this BIT was for. When I came across this question in the soft exam, I was shocked. Let’s take a look together.

The question asked us to select an incorrect option. According to the definitions above, options A and B are fine, and option D, which is vague, is also not wrong, so the correct answer is C.

The non-destructive algorithm is used in periodic BIT, not maintenance BIT. Maintenance BIT is conducted under maintenance status, so when I am maintaining, there is naturally no need to ensure the system is running normally (just like when we play games, we cannot access the game server during maintenance).

First, we need to know three concepts: process, thread, task. Those familiar with Linux system programming should be familiar with these concepts, while those with no foundation should remember the following points.

A process is the basic unit of resource allocation, and a thread is the smallest unit of independent scheduling.

A task runs on top of a process or thread, meaning the process and thread are the carriers of the task.

The soft exam mainly tests the state diagram of processes, with the mainstream being the three-state and five-state diagrams. Let’s look at the three-state diagram; once we understand the three-state, we can also understand the five-state, and the soft exam mainly tests the three-state diagram.

The three states are: running, waiting, ready.

A process needs corresponding resources to run. If the required resources are currently occupied by others, the process is in a waiting state. A process can be running, then needs a resource and switches to a waiting state, meaning it transitions from running to waiting.

When a waiting process obtains the resource it is waiting for, it transitions from the waiting state to the ready state.

A process in the ready state has the conditions to run; it just needs to wait for its time slice to come around to transition from the ready state to the running state. Similarly, if a running process’s time slice expires, it will transition from the running state to the ready state, waiting for the next time slice.

The transitions of the three states refer to the arrows in the diagram above; the arrows are unidirectional, and with careful thought, it should not be difficult to understand.

Let’s practice a question.

First of all, neither the three-state model nor the five-state model includes the revoke state, so D can be eliminated.

After resources are allocated, a process enters the ready state, and after obtaining a time slice, it enters the executing state, so the answer to this question is B.

First, let’s look at a precedence diagram.

The left box indicates that ABCD must all be completed before proceeding to E, and no matter how fast A runs, it still has to wait for BCD to finish before moving on to the next step, which is called synchronization.

The right box means that EFGH must be executed in order, possibly because they all need to use the same resource, which cannot be shared among them and must be accessed in turn, which is called mutual exclusion.

A semaphore is a special variable that allows for PV operations. The P operation can be seen as taking, which decreases the semaphore by one. If the semaphore’s value is less than 0, the program will block until another process increases the semaphore, making its value greater than or equal to 0, at which point the program can continue running.

The V operation can be seen as giving, which increases the semaphore by one.

Based on the characteristics of PV operations, we can perform a P operation followed by a V operation, placing a segment of code between these two operations that involves resources that can only be used by one process or a limited number of processes, thus controlling the number of processes that can access the resource at the same time.

Such questions typically appear in the afternoon’s major topics, often with code snippets provided for completion.

Process scheduling is used between the ready and running states, and we need to allocate time slices to processes using scheduling algorithms.

Common scheduling algorithms include the following:

First-Come, First-Served: executes processes in the order they arrive.

Round Robin: similar to First-Come, First-Served, it allocates time slices to processes, but unlike First-Come, First-Served, which executes a process completely before moving to the next, Round Robin divides the time slice into uniform intervals, allowing processes to execute for a time slice in order, with each process typically requiring several time slices, continuing round after round until all processes are completed.

Shortest Job First: executes processes based on the shortest required time, regardless of order.

Priority Scheduling: assigns different priorities to different processes, arranging execution order based on priority, with processes of the same priority executed in First-Come, First-Served order.

Deadlock occurs when process A needs resources a and b, currently has resource a, and is waiting for resource b. Meanwhile, process B also needs resources a and b, currently has resource b, and is waiting for resource a. This results in both processes holding resources that the other needs while waiting for the other to release resources, leading to a deadlock—caused by unreasonable resource allocation, causing the entire program to block.

There are four necessary conditions for deadlock; breaking any one of them can resolve the deadlock:

Resource mutual exclusion.

Each process holds resources while waiting for other resources.

The system cannot deprive processes of resources.

There is a circular chain in the process resource graph, meaning there exists a cyclic chain of processes waiting for resources held by the next process.

To avoid deadlock, the Banker’s algorithm is generally used, which essentially calculates whether there is a method to avoid deadlock before allocating resources. The specifics of the Banker’s algorithm can be searched for; it’s quite simple.

There are three concurrent processes, meaning three processes are executed together. Each process needs four of the same resource. The question asks how many resources are needed to avoid deadlock.

This type of question has a fixed template, but let’s not discuss the formula just yet. Let’s consider what situations could lead to deadlock.

The worst-case scenario is if I occupy a lot of resources but do not have enough to run, meaning I could occupy up to 3 resources, which implies that 3 * 3 = 9 resources could lead to deadlock.

In this case, if I add one more resource, no matter who this additional resource is given to, it will satisfy the conditions for running—having four resources. After running, the resources will be released (V operation), and the remaining two processes will have enough resources to run, thus avoiding deadlock.

Hence, the formula is Number of processes * (Maximum required resources – 1) + 1