Synchronization and mutual exclusion and deadlock problem of Linux environment offline thread

Because of this minor discussion of the operating system deadlock problem, we must first study the Linux environment of thread synchronization and mutual exclusion

First look at the following code

650) this.width=650; "Src=" Http://s5.51cto.com/wyfs02/M00/84/3A/wKioL1eIq6vSobvSAACO3LC1gto546.png-wh_500x0-wm_3 -wmp_4-s_3162558152.png "title=" 1.png "alt=" Wkiol1eiq6vsobvsaaco3lc1gto546.png-wh_50 "/>

What do you suppose the output should be?

The result is the following.

650) this.width=650; "Src=" Http://s4.51cto.com/wyfs02/M02/84/3A/wKioL1eIrEyyrc4eAAAepJqF-Xc171.png-wh_500x0-wm_3 -wmp_4-s_3049077643.png "title=" 2.png "alt=" Wkiol1eireyyrc4eaaaepjqf-xc171.png-wh_50 "/>

Well, there doesn't seem to be any difference ...

Then look at the code below (please ignore and ignore the masked content ...) ）

650) this.width=650; "Src=" Http://s2.51cto.com/wyfs02/M02/84/3B/wKioL1eIrQezuDWlAADtLIFvvss063.png-wh_500x0-wm_3 -wmp_4-s_1282612018.png "title=" 3.png "alt=" Wkiol1eirqezudwlaadtlifvvss063.png-wh_50 "/>

What do you suppose is the right result? 5000,10000?

Well, maybe you're all wrong.

After running for a while, the result is this.

650) this.width=650; "Src=" Http://s3.51cto.com/wyfs02/M00/84/3B/wKioL1eIrb2S3rjJAAAHZ6RD-KY633.png-wh_500x0-wm_3 -wmp_4-s_1809902655.png "style=" Float:none; "title=" 6-copy. png "alt=" wkiol1eirb2s3rjjaaahz6rd-ky633.png-wh_50 "/>

650) this.width=650; "Src=" Http://s3.51cto.com/wyfs02/M00/84/3B/wKioL1eIrb6xr9w-AAAGyTltVN8437.png-wh_500x0-wm_3 -wmp_4-s_2635848277.png "style=" Float:none; "title=" 4-copy. png "alt=" wkiol1eirb6xr9w-aaagytltvn8437.png-wh_50 "/>

650) this.width=650; "Src=" Http://s4.51cto.com/wyfs02/M00/84/3B/wKiom1eIrb6iLgjgAAAGvnbAHBs428.png-wh_500x0-wm_3 -wmp_4-s_111981103.png "style=" Float:none; "title=" 5-copy. png "alt=" wkiom1eirb6ilgjgaaagvnbahbs428.png-wh_50 "/>

Is it right and wrong?

Why is it?

This is because the function of the printf statement in the program: itself is a library function, so must make system calls, must enter the kernel to switch, there is a large probability of formation of data chaos

To prevent data clutter during kernel switching, introduce the pthread_mutex_t type (mutex)

If you change the program to look like this (OK, actually is to remove the shield just now ...) ）

650) this.width=650; "Src=" Http://s3.51cto.com/wyfs02/M02/84/3B/wKioL1eIrlXjS4-hAADinhgmU2s786.png-wh_500x0-wm_3 -wmp_4-s_180884655.png "title=" 7.png "alt=" Wkiol1eirlxjs4-haadinhgmu2s786.png-wh_50 "/>

Note The starting global variable pthread_mutex_t type of lock and Pthread_mutex_lock in the while loop in the function and the use of Pthread_mutex_unlock

To view the program run results:

650) this.width=650; "Src=" Http://s4.51cto.com/wyfs02/M00/84/3B/wKiom1eIrxCxEDZDAAAIp7ys6zk454.png-wh_500x0-wm_3 -wmp_4-s_2761962580.png "style=" Float:none; "title=" 8.png "alt=" Wkiom1eirxcxedzdaaaip7ys6zk454.png-wh_50 "/>

650) this.width=650; "Src=" Http://s1.51cto.com/wyfs02/M00/84/3B/wKioL1eIrxDjq1C4AAARYxHOcpU040.png-wh_500x0-wm_3 -wmp_4-s_3689100010.png "style=" Float:none; "title=" 9.png "alt=" Wkiol1eirxdjq1c4aaaryxhocpu040.png-wh_50 "/>

650) this.width=650; "Src=" Http://s4.51cto.com/wyfs02/M01/84/3B/wKiom1eIrxDC8e9AAAAPdsA_QUY782.png-wh_500x0-wm_3 -wmp_4-s_4188923755.png "style=" Float:none; "title=" 10.png "alt=" Wkiom1eirxdc8e9aaaapdsa_quy782.png-wh_50 "/>

Is the result exactly the same?

Well, that's the charm of the Pthread_mutex lock.

So, what is sometimes a deadlock?

Deadlock (Deallocks): Refers to two or more than two processes (threads) in the course of execution, because of the contention for resources caused by a mutual waiting phenomenon, if there is no external force, they will not be able to proceed. At this point, the system is in a deadlock state or the system generates a deadlock, and these processes (threads) that are always waiting on each other are called deadlock processes (threads). Because resource consumption is mutually exclusive, when a process requests resources, so that the process (threads) without external assistance, never allocated the necessary resources and can not continue to run, which creates a special phenomenon-deadlock.

Deadlock-generated conditions:

Four necessary conditions for generating a deadlock

(1) Mutex condition: A resource can only be used by one process (thread) at a time.

(2) Request and hold condition: When a process (thread) is blocked by a request for resources, the acquired resources are persisted.

(3) No deprivation condition: the resources that this process (thread) has obtained cannot be forcibly stripped until the end of use.

(4) Cyclic wait condition: a cyclic waiting resource relationship between multiple processes (threads) is formed.

These four conditions are necessary for the deadlock, as long as the system has a deadlock, these conditions must be established, and as long as one of the above conditions is not satisfied, there will be no deadlock.

release and prevention of deadlocks :

Understanding the causes of deadlocks, especially the four necessary conditions that generate deadlocks, can prevent, prevent, and unlock deadlocks to the maximum possible. Therefore, in the system design, process scheduling and other aspects of how to not let these four necessary conditions to set up, how to determine the rational allocation of resources algorithm, to avoid the process of permanent occupation of system resources. Also, prevent the process from consuming resources while it is in a wait state. Therefore, the allocation of resources should be given reasonable planning.

Synchronization and mutual exclusion and deadlock problem of Linux environment offline thread