UC/OS-II parasitic simulation in Windows

(This article is original. For more information, see the source)

Since the uC/OS-II under the virtual problem, many friends leave a message for me, :), here, thank you for your criticism. I hope you can leave a message directly on my blog, and leave a comment less on QQ. These technical questions will be discussed on the blog and will become clearer. It is easy to leave a message on QQ.

In particular, the "Pathfinder" posted a message to me for your research:

08:49:22 Pathfinder:

UC/OS-II windows virtual problem: I think there is a problem with your analysis.
08:51:47 Pathfinder:
For Windows and Linux, processes are the smallest units that can be scheduled by the operating system, and threads are the smallest units that can be scheduled by processes.
08:54:21 Pathfinder:
The ucosii program is run as the smallest unit that the operating system can schedule-the process. The operating system does not recognize the internal operation of the ucosii program, such as multithreading.
09:01:25 Pathfinder:
For the operating system, there is only process switching, but no thread switching.
09:01:52 Pathfinder:
For a single process, thread switching exists.
10:06:04 Pathfinder:
For the first problem: there is no separate thread switch, but there is only a process switch. Although the real-time performance of ucosii is not guaranteed, the integrity of the overall ucosii (process) operation is guaranteed.

10:09:24 Pathfinder:
For the second problem: Since resources are shared, the problem of mutual exclusion will be considered. Before and After accessing the critical resources of Windows and Linux operating systems, consider locking and unlocking.
10:14:55 Pathfinder:

I am also worried about this issue because I am using it and want to apply it to a control system. If I use it rashly, there will be an alarm EMU, which is troublesome.

Here I do not want to say, "uC/OS-II under the virtual problem" has been very clear, here is a practical example:

Void task1 (void * PARAM)

{

While (1)

{

Printf ("Haha... you are in Task 1. \ n ");

Ostimedly (40 );

}

}

Void task2 (void * PARAM)

{

While (1)

{

Printf ("Haha, you are in Task 2. \ n ");

Ostimedly (20 );

}

}

Void task3 (void * PARAM)

{

While (1)

{

Printf ("Haha, you are in Task 3. \ n ");

Ostimedly (20 );

}

}

These three tasks are simple tasks. Now we assume that task 1 has the highest priority level, Task 2 has the second priority level, and task 3 has the lowest priority level. The printf function is used to output data to the screen. To prevent output confusion, the printf function has a Windows Lock to prevent data disorder on the screen. Because of this lock, the output information we see will not have the following output:

Haha, you are Haha, in Task 2.

You are in Task 3.

If the printf function in the Windows library is used for simulation on Windows, this lock cannot be circumvented. To facilitate discussion, we can simplify printf to the following pseudocode:

Int printf (char * FMT ,...)

{

Char * lines [max_output];

* Lines = '\ 0 ';

...; // Output print data to lines;

Lockscreen (); // acquire lock.

Output2screen (lines );

Unlockscreen (); // release lock.

Return ...;

}

If all the printf statements originally run from UC/OS-II to task 3 are completed, there is nothing to do. Suppose that the ouput2screen () is running at lockscreen. UC/OS-II think you have time to run Task 1. If you run lockscreen () in printf, Task 1 cannot be executed. Only other tasks can be executed, or task 3 can be executed until unlockscreen (). Task 1 can continue execution.

Let's take a closer look:

Lockscreen () is not a UC/OS-II lock.

UC/OS-II does not know that task3 has entered a critical area, in a Windows transplant, the uC/OS-II core will call suspendthread () to suspend task3, task3 does not resume the execution, task 3 can resume execution only when the scheduling algorithm of uC/OS-II calls resumethread. When the scheduling algorithm calls resumethread to resume Task 1 execution and encounters lockscreen, Task 1 enters the blocking state, which is the blocking state of windows, in the UC/OS-II core, Task 1 is still the running state.
But in fact, Task 1 is dead, and all tasks with lower priority than Task 1 are over. If Task 1 is the highest priority task, the whole uC/OS-II although not dead, but the phenomenon is all dead.

I want to explain the entire process clearly. The process of simulation is also very simple, and it is easy to be online on VC ++. Because it is not a must-have problem, you can get a few more printf tasks to increase the probability of appearance. Through the thread observation window and callstack window, we can see that both task1 and task3 are suspended in printf. It stops at the core of windows. Welcome !!!

(This article is original. For more information, see the source)