Critical area problems caused by Rt-thread multithreading

A critical resource is a shared resource that is allowed to be used by only one thread at a time. Whether it is a hardware critical resource or a software critical resource, multiple threads must be mutually exclusive to access them. The code that accesses the critical resource in each thread is called the Pro
Zone (Critical section), only one thread is allowed to enter the critical section at a time, and no other threads are allowed to enter. multithreaded programs are developed in a way that differs from bare-metal applications, where multiple threads are running concurrently on a macro level, so using a shared resource is a need to be aware of, or there may be incorrect results.

#include <rtthread.h>#include<stm32f10x.h>#include"test.h"rt_uint32_t g_tmp;/*define a global variable*//*Variable allocation 4-byte alignment*/ALIGN (rt_align_size)/*thread stacks for static threads*/Staticrt_uint8_t thread1_stack[ +];Staticrt_uint8_t thread2_stack[ +];/*thread control blocks for static threads*/Static structRt_thread Thread_test1;Static structRt_thread Thread_test2;Static voidTest1_thread_entry (void*parameter);Static voidTest2_thread_entry (void*parameter);voidDemo_thread_creat (void) {rt_err_t result; /*Create a static thread: Priority 15, time slice 2 system tick*/result= Rt_thread_init (&Thread_test1,"test1", Test1_thread_entry, Rt_null, (rt_uint8_t*) &thread1_stack[0],sizeof(Thread1_stack), -,2); if(Result = =Rt_eok) {Rt_thread_startup (&thread_test1); }    /*Create a static thread: Priority 16, time slice 1 system tick*/result= Rt_thread_init (&Thread_test2,"test2", Test2_thread_entry, Rt_null, (rt_uint8_t*) &thread2_stack[0],sizeof(Thread2_stack), the,1); if(Result = =Rt_eok) {Rt_thread_startup (&thread_test2); }}voidTest1_thread_entry (void*parameter)    {rt_uint32_t i; G_tmp=0; rt_kprintf ("g_tmp=:%d \ r \ n", g_tmp);  for(i=0; i<10000; i++) {g_tmp++; } rt_kprintf ("g_tmp=:%d \ r \ n", g_tmp);}voidTest2_thread_entry (void*parameter) {Rt_thread_delay ( -);//1Rt_thread_delay (100);get two pictures in two cases

g_tmp++;
}

Results Analysis:
In the test1 thread's for loop we have done 10,000 increments on I, and if there is no "intervention" for the other thread, then the value of the global variable g_tmp should be 10000, and now the output is 10001, which means that the value of the global variable g_tmp has been modified by thread 2. The state of each thread during the entire program is changed: After creating two threads in Rt_application_init, the test2 thread runs first, and the first sentence of its threading function is rt_ because the test2 thread has a higher priority than the TEST1 thread. Thread_delay (1), which causes the test2 thread to be suspended, hangs for 1 time slices, and the test1 thread is the highest priority thread in all ready-state threads during the time the test2 thread hangs, so it is run by the kernel scheduler. After the test1 thread executes a portion of the code, the 1 tick time, the test2 thread is awakened, and thus becomes the highest priority thread in all ready threads, so it is scheduled to run immediately, test1 thread is preempted by test2 thread, test2 the global variable g_tmp thread Do the cumulative operation, the next test2 thread execution, the test1 thread is scheduled to run again, according to the program's running results can be seen, at this time the TEST1 thread continues to execute, but we do not know at this time the test1 thread is roughly from where the start of execution, from the final output of the results, Only to know that at this point the test1 thread has not yet executed to the second RT_KPRINTF output statement. The last test1 thread prints the value of the global variable g_tmp again, and its value should be 10001. When the first sentence in the test2 thread is rt_thread_delay (100), the test1 thread has been executed for the entire time the test2 thread sleeps, so the final output is 10000.
As you can see from the above: when public resources are common across multiple threads, the final output may be completely different from the expected results if the necessary protection errors are lacking. In order to solve this problem, we need to introduce the inter-thread communication mechanism, which
is the so-called IPC mechanism (inter-process communication).

Critical area problems caused by Rt-thread multithreading