"Go" thread priority and thread-safe

Thread Priority

The task scheduling of major operating systems (such as Windows, Linux, Mac OS X) now has the characteristics of priority scheduling (Prioroty Schedule) In addition to the time-slice rotations mentioned earlier. Priority scheduling determines the order in which threads are executed in turn, and in systems with priority scheduling, threads have their own thread priority. Threads with high priority are executed earlier, while low-priority threads are typically executed when there are no higher-priority executable threads.

The priority of a thread can be set manually by the user, and the system will adjust the priority according to different situations. Typically, threads that enter a waiting state frequently (such as an IO thread) that go into a waiting state to discard a share of the time that is still available before the wait status, are more popular with the operating system than a thread that is heavily computationally intensive every time . Because threads that frequently enter the waiting space only take up a very small amount of time, the operating system can handle more tasks. We refer to threads that are waiting frequently as io-intensive threads (IO Bound thread), while threads that are seldom waiting are referred to as CPU-intensive threads (CPU Bound thread). IO-intensive threads are always more prone to priority improvements than CPU-intensive threads.

Thread starved

Under the priority scheduling, it is prone to a thread starvation phenomenon. A thread starved to death is to say that it has a lower priority, and there are always higher priority threads waiting to execute before it executes, so this low-priority thread is never executed. When CPU-intensive threads are high-priority, other low-priority threads are likely to starve, and when IO-intensive threads are higher priority, other threads are relatively less likely to starve, because IO threads have a lot of waiting time. to prevent threads from starving, the scheduling system usually increases the priority of those threads that are waiting long enough to be executed. In this way, a thread will always be promoted to the point where it can be executed as long as it waits long enough, that is, it is only a matter of time before the threads are always executed. 　　

　

In a priority scheduling environment, there are three ways to change the priority of a thread:
1. user-specified priority ;
2. increase or decrease the priority (completed by the operating system) based on the frequency of entering the waiting state;
3. priority is promoted for a long time without execution .

Thread Safety and lock

When multiple threads concurrently execute access to the same data, it can be very risky to do so without taking appropriate action. Suppose you have a bank account in ICBC, two UnionPay cards (one in your hand, one in your girlfriend's hand), and 1 million inside. Suppose you take money on two processes: 1. Check the balance of the account, 2. Withdraw Cash (if the amount to be withdrawn > account balance, the withdrawal is successful, otherwise the withdrawal fails). One day you want to buy a house to get the money out, and at this time your girlfriend also want to buy a car (assuming you have not discussed beforehand). Two people are taking the money, you take 1 million on the A ATM machine, the girlfriend takes 800,000 in the B ATM machine. At this time, a ATM check account balance found 1 million, can be removed, while at the same time, B ATM is also checking the account balance found that 1 million, can be taken out, so that a, b all the money out.

1 million of the deposit out of 1.8 million, the bank will lose money (of course you smiling ...)! This is the non-security of thread concurrency. To avoid this, we will synchronize access to the same data by multiple threads to ensure thread safety.

The so-called Synchronization (synchronization) means that when a thread accesses data, other threads must not access the same data, that is, only one thread can access the data at the same time, and other threads will be able to access it at the end of this process. The most common way to synchronize is to use a lock, also known as a thread lock. A lock is a non-mandatory mechanism in which each thread attempts to acquire (acquire) a lock before accessing the data or resource and releasing the (release ) lock After the end of the visit. When an attempt is made to acquire a lock when the lock is occupied, the thread goes into a wait state until the lock is released and becomes available again.

Binary signal Volume

　　The two-dollar semaphore (binary Semaphore) is the simplest type of lock that has two states: occupancy and non-occupancy. It is suitable for resources that can only be accessed exclusively by a single thread. when the two-dollar semaphore is in a non-occupied state, the first thread that attempts to acquire the two-dollar semaphore lock acquires the lock and locks the two-dollar semaphore to occupy state, after which other threads attempting to acquire the two-dollar semaphore enter the wait state until the lock is released .

Signal Volume

　　multivariate semaphores allow multiple threads to access the same resource, a multivariate semaphore called the Semaphore (Semaphore), which is a good choice for resources that allow concurrent access by multiple threads. A semaphore with an initial value of n allows n threads to access concurrently. When a thread accesses a resource, it first acquires a semaphore lock, doing the following:
1. reduce the value of the semaphore by 1;
2. if the semaphore value is less than 0, then enter the waiting state, otherwise continue execution ;

After the access resource ends, the thread releases the semaphore lock, doing the following:
1. Add the value of the semaphore to 1;
2. if the value of the semaphore is less than 1 (equal to 0), wake up a waiting thread ;　

Mutex Amount

　　A mutex (mutex) is similar to a two-dollar semaphore, and the resource allows only one thread to access it. Unlike the two-dollar semaphore, semaphores can be obtained and freed by arbitrary threads throughout the system, meaning that the same semaphore can be fetched by one thread and freed by another. The mutex requires which thread gets the mutex to be freed by which thread, and the other thread someone else to release the mutex is invalid .

Critical section

The Critical Zone (Critical section) is a more stringent synchronization method than the mutex. mutexes and semaphores are visible in any process of the system, meaning that a process creates a mutex or semaphore, and another process attempts to acquire the lock is legal. The scope of the critical section is limited to this process, and other processes cannot acquire the lock . In addition to this, the critical section and the mutex are of the same nature.　

Read/write Lock

The read-write lock (Read-write Lock) allows multiple threads to read the same data at the same time, allowing only one thread to write. This is because the read operation does not change the contents of the data, it is secure, and the write operation alters the contents of the data, which is not secure. For the same read-write lock, there are two ways to get it: Shared and Exclusive (Exclusive). When the lock is in a Free State , attempts to acquire the lock in either way (shared or exclusive) can succeed , and the lock is set to the corresponding State;

　　If the lock is shared , the other thread acquires the lock in a shared manner, and the lock is assigned to more than one thread, and if another thread tries to acquire the shared lock in an exclusive way, it must wait for all threads to release the lock;

　　If the lock is in exclusive state , it prevents any thread from acquiring the lock, regardless of how they are .

The way to get read and write locks is summarized as follows:　　

　　

Reprint Source :http://blog.csdn.net/luoweifu/article/details/46701167

　　

"Go" thread priority and thread-safe