Shulou(Shulou.com)06/03 Report--

This article mainly explains "what is the randomness of thread scheduling". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought. Let's study and learn "what is the randomness of thread scheduling"?

Several basic knowledge points of thread scheduling

In multithreaded concurrent execution, many students do not know what problems the randomness of scheduling will lead to, knowing that unlocked access to critical resources will lead to some emergencies or even deadlocks.

With regard to thread scheduling, you need to deeply understand the following basic knowledge points:

The smallest unit of scheduling is a lightweight process (for example, the simplest C program we wrote in hello world, which executes as a lightweight process) or thread

Each thread will be assigned a time slice, and when the time slice arrives, the next thread will be executed.

The scheduling of threads is random, so it is impossible to determine when it will be scheduled.

Within the same process, all threads created by the process share except the local resources created within the thread, and all other resources created by the process are shared by all threads; for example, both main threads and child threads can access global variables, open file descriptors and so on.

Example

No matter how many theories are not as straightforward as a visual example.

Expected code timing

Suppose we are going to implement an example of multithreading, and the expected sequence of program execution is as follows:

Expected time series

Expected functional timing:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

The main process creates child threads, and the child thread function function ()

The main thread count adds itself and assigns values to value1,value2 respectively

When the time slice is up, switch to the child thread, which determines whether the values of value1 and value2 are the same, and prints the value of the information value1,value2,count if they are different. But because the main thread assigns count to value1,value2 successively, the value of value1,value2 should never be the same, so you should not print anything.

Repeat steps 2 and 3.

Code 1

All right, now let's write the code in this sequence as follows:

1 # include 2 # include 3 # include 4 # include 5 # include 67 unsigned int value1,value2, count=0; 8 void * function (void * arg); 9 int main (int argc, char * argv []) 10 {11 pthread_t athread; 12 13 if (pthread_create (& a_thread, NULL, function, NULL) < 0) 14 {15 perror ("fail to pthread_create"); 16 exit (- 1) 17} 18 while (1) 19 {20 count++; 21 value1 = count; 22 value2 = count; 23} 24 return 0 25} 26 27 void * function (void * arg) 28 {29 while (1) 30 {31 if (value1! = value2) 32 { 33 printf ("count=%d Value1=%d, value2=%d\ n ", count, value1, value2) 34 usleep (100000); 35} 36} 37 return NULL; 38}

At first glance, the program should be able to meet our needs, and the program should not print anything, but the actual results are unexpected.

Compile and run:

Gcc test.c-o run-lpthread. / run

Code 1 execution result

Execution result:

You can see that the subroutine will print some information at random, why is there such an execution result? In fact, the reason is very simple, that is, as we said at the beginning of the article, thread scheduling is random, and we cannot specify when the kernel will schedule a thread. If there is printed information, this means that the values of value1 and value2 are different at this time, and that when dispatching child threads, they are scheduled to the location between value1 and value2 in the main thread.

The actual timing of code 1 execution

In fact, the execution sequence of the code is as follows:

As shown in the figure above, at some point, when the program reaches the position of * * value2 = count;**, the kernel schedules the thread, so when the child process judges the values of value1 and value2, it finds that the values of the two variables are different, and has the print information.

There is a good chance that the program will schedule between the following two lines of code.

Value1 = count; value2 = count

Solution method

How to solve the problem that the program does not execute as expected due to concurrency? For threads, the commonly used methods are posix semaphores, mutexes, condition variables and so on. Let's take mutexes as an example to explain how to avoid the problem of code 1.

Definition and initialization of mutex:

Pthread_mutex_t mutex; pthread_mutex_init (& mutex, NULL)

Apply for release of the lock:

Pthread_mutex_lock (& mutex); pthread_mutex_unlock (& mutex)

Principle: apply for the lock before entering the critical area, continue to execute if the lock can be obtained, and hibernate until other threads release the lock.

Code 2

1 # include 2 # include 3 # include 4 # include 5 # include 6 # define _ LOCK_ 7 unsigned int value1,value2, count=0; 8 pthread_mutex_t mutex; 9 void * function (void * arg); 10 11 int main (int argc, char * argv []) 12 {13 pthread_t a_thread 14 15 if (& mutex, NULL) < 0) 16 {17 perror ("fail to mutex_init") 18 exit (- 1); 19} 20 21 if (& a_thread, NULL, function, NULL) < 0) 22 {23 perror ("fail to pthread_create"); 24 exit (- 1); 25} 26 while (1) 27 {28 count++; 29 # ifdef _ LOCK_ 30 pthread_mutex_lock (& mutex); 31 # endif 32 value1 = count 33 value2 = count; 34 # ifdef _ LOCK_ 35 pthread_mutex_unlock (& mutex); 36 # endif 37} 38 return 0; 39} 0 41 void * function (void * arg) 42 {43 while (1) 44 {45 # ifdef _ LOCK_ 46 pthread_mutex_lock (& mutex) 47 # endif 48 49 if (value1! = value2) 50 {51 printf ("count=%d, value1=%d, value2=%d\ n", count, value1, value2); 52 usleep (100000); 53} 54 # ifdef _ LOCK_ 55 pthread_mutex_unlock (& mutex); 56 # endif 57} 58 return NULL; 59}

As shown in the above code: when the main thread and child threads want to access the critical resource value1,value2, they must first apply for a lock, acquire the lock before they can access the critical resource, and release the mutex after the access. No information is printed after the code is executed. Let's take a look at the timing diagram of the program if it generates scheduling between the following codes.

Value1 = count; value2 = count

The timing diagram is as follows:

As shown in the above figure:

At time n, the main thread gets the mutex and enters the critical section.

Time nasty 1, time slice is up, switch to child thread

The child thread could not apply for the lock mutex, so it abandoned cpu and went into hibernation

At 3: 00, the main thread releases mutex, leaves the critical area, and wakes up the child threads blocking in mutex. The child threads apply to mutex and enter the critical area.

The child thread leaves the critical area and releases the mutex at the moment of Number4.

As you can see, after locking, even if the main thread produces a schedule before value2 = count;, the child thread will sleep because it cannot get the mutex. Only when the main thread is out of the critical section, the child thread can get mutex, access value1 and value2, and will never print information, thus realizing the expected code timing.

Thank you for your reading, the above is the content of "what is the randomness of thread scheduling". After the study of this article, I believe you have a deeper understanding of the randomness of thread scheduling. the specific use of the situation also needs to be verified by practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.