Virtual problem in UC/OS-II windows

(For Original Articles, please indicate the source. Thank you)

Domestic uC/OS-II with a lot of people, recent uC/OS-III is also open source, it is the majority of RTOS fans of the blessing. I have also developed some things with uC/OS-II. At that time, it was simulated on Windows platform with uC/OS-II. A "Hello world!" is run !!!"; Generally feel that this virtual method is not bad, can combine visual C ++ such powerful tools, or Linux platform GDB such a tool, the uC/OS-II code do a single step tracking; a deep understanding of the RTOS kernel execution process. I think it is very good. However, after I have a deep understanding of the RTOS kernel and the transplantation of uC/OS-II on windows, I find that this virtual approach is easy to harm ......

Where is the problem? First, RTOS is different from windows, Linux, and uClinux systems, mainly because its scheduling algorithm is different. The Rate Monotonic (RM monotonous rate) scheduling algorithm is used. The biggest feature of this algorithm is the priority-based time allocation. If a high-priority task does not give up its CPU occupation, the kernel of the operating system cannot be executed in time. This is definitely not the case in Windows or Linux. Even if a task accounts for 100% of the CPU, the user's operations are slow and cannot be moved.

That uC/OS-II transplantation on the Windows platform, how to do it? UC/OS-II tasks are implemented using Windows threads, using ostaskcreate is to create a windows thread, the entry is the user specified task. There is a problem here, uC/OS-II more core OS _enter_critical and OS _exit_critical is how to achieve? Implemented using the binary semaphore in windows. This binary semaphore is only used within a process, but can be used in multiple threads within the same process. Therefore, context switching does not have much practical content. It only calls the Windows API to resume the execution of high-priority tasks (a thread for Windows), while low-priority tasks are suspended. The context content is saved for RTOs in windows.

The clock cycle of the system is provided by the Windows multimedia clock. The ostickw32 function is run as an independent thread. Execute ostickisr () once the time is reached ().

DWORD winapi ostickw32 (lpvoid lpparameter)
{
OS _init_critical ();

While (! Osterminatetickw32)
{
Ostickisr ();
# Ifdef win_mm_tick
If (waitforsingleobject (ostickeventhandle, 5000) = wait_timeout)
{
# Ifdef OS _cpu_trace
OS _printf ("error: Mm ostick timeout! \ N ");
# Endif
}

Resetevent (ostickeventhandle );

# Else
Sleep (1000/OS _ticks_per_sec );
# Endif
}

Return 0;
}

Although the task scheduling algorithm is based on Windows, the original intention of the RMS scheduling algorithm can be basically guaranteed by regularly executing the kernel code.

Although Virtual tasks in Windows basically meet the RMS scheduling rules, careful analysis is not the case. First, all thread priority levels are the same for Windows. It's not because uC/OS-II gives him a high priority, and he gets more execution time. If the entire uC/OS-II virtual process is running in a heavy environment, the execution time is uncertain no matter what low-priority and high-priority tasks are.
Again, the uC/OS-II task is based on Windows, the global critical area is also achieved by using Windows's binary semaphore. Generally, the scheduler and interrupt System of the uC/OS-II can be locked with the global critical area. However, don't forget that the uC/OS-II task and scheduler are locked and Windows scheduler is not locked. It can still complete thread switching. Does not affect Windows Thread switching. Since Windows Thread switching is dominated by uC/OS-II, it's okay, this doesn't have any problem; but in turn, if windows thread switching is disabled, and no notification to UC/OS-II, then it will be finished. UC/OS-II forces windows to switch to a task, causing the entire system deadlock (locked ).

This situation is complicated: for example, task a is a low-priority task and is calling a Windows Io function. This Io is a critical Io and has just entered the critical region of this Io, not yet. When the time is reached, uC/OS-II forces windows to switch to the ready state of the B task, B task priority level higher than. Unfortunately, B also wants to call the same IO function and enter the same critical area. So, we can see that the line B cannot get the lock, and B will wait for a to put the lock, this is windows level, for uC/OS-II, it also thinks B is executing. And a task because the B task is being executed, permanent wait, this is the uC/OS-II layer, so the uC/OS-II will not switch the scheduler to let B stop the execution, let a execute, to unlock the deadlock. Even if all the threads of the process are not executed, it is also allowed for Windows. For uC/OS-II, it is always running B tasks, while B tasks are waiting for a lock that he will never get.

Scheduling is completed by the Windows core, but I/O operations and some substantive operations must be completed by calling Windows APIs. If these Apis potentially affect Windows scheduling, the simulation fails if the uC/OS _ii is not known. In addition, this situation can occur only when specific conditions are met. In reality, debugging is difficult to determine the location of the problem. But there is also a solution, to all Windows API, the API called in the task as a critical area of the uC/OS-II, there will be no deadlock. However, this will generate a huge simulation overhead.

Compared with this parasitic simulation method, Skyeye and qemu are more superior and closer to reality. Although they also have their own problems, at least they will not have the above two problems. Therefore, for RTOs developers, choosing a proper virtual method has a huge impact on development.

(For Original Articles, please indicate the source. Thank you)