[Go] Thread synchronization

In scenario one, scenario two, I introduce the solution when multithreading encounters "resource Contention" and "limited use", this is the final scenario in this series, and describes several scenarios for solving thread communication.

Scenario Three: I let you move, you can move!

Sledgehammer: "Boss, take this cell phone let me see".

Sledgehammer: "Is this a cell phone???" were just a shell. "

Boss: "Ah, this may be a problem in production, I will give you a change!" ”

Sledgehammer: "Boss, you this is when I am a fool?" Or a fool? Or a fool? This time to my phone why no power Ah! How do I turn on the boot? ”

Never thought, after thousands of choices, eventually found an accessory complete mobile phone.

The boss went back and found the reason is: production and online sales two links did not match well, when the production process has not ended, the intermediate products to be sold.

solution : All actions can not be executed without authorization, must obey the order, when the production process will be notified on-line link, and then be allowed to go to the market to sell.

problem Abstraction : When the execution of an operation must depend on the completion of another operation, a mechanism is required to ensure that the order of precedence.

Thread Communication Scenarios : ManualResetEventSlim, ManualResetEvent, AutoResetEvent

Scenario feature : the ability to provide thread notifications, the thread must wait, and have precedence before receiving notification .

The difference between the programmes

Before you continue reading, make sure you have an understanding of user-mode constructs, kernel-mode constructs, and mixed-mode constructs, and if not, it is recommended that you read the relevant chapters in scenario one first.

Kernel mode (kernal-mode)

Both ManualResetEvent and AutoResetEvent inherit from EventWaitHandle and eventually share the same ancestor as the Mutex and Semaphore: WaitHandle. In the previous few I have said that WaitHandle is an abstract class that wraps the kernel object handle of the Windows operating system.

ManualResetEvent: Chinese understanding is the manual reset event (the event here is not the kind of event in our usual sense of the button, more should be understood as an announcement). The initial state of all events is "not available", and any thread waiting for the event will wait forever. Only when a signal is released through the Set method does the thread waiting for the event be allowed to perform the required operation. If you do not reset manually, the status is always available, and any thread that waits for the event can continue to perform the operation. The state will become unavailable only if the Reset method is called. The state is requested by WaitOne to decide whether to perform the operation.

This feature is somewhat similar to a traffic light, when the green light is on, all motor vehicles are allowed to pass until they turn red again.

Unlike mutexes, Reset and Set operations can be initiated by different threads. Such as:

12345678910111213141516

ManualResetEvent s = newManualResetEvent(false);    Task.Factory.StartNew(() =>    {        s.Set();    });    Task.Factory.StartNew(() =>    {        s.Reset();    });        Task.Factory.StartNew(() =>    {        s.WaitOne();    });

Pros: Provides the ability to communicate between threads, which can be used across processes.

Cons: Slower than user mode, mixed mode construction, slightly faster than mutex.

AutoResetEvent: As the name implies, automatically resets events. If the manulresetevent is equivalent to a traffic light, the AutoResetEvent is similar to the high-speed entrance gate, the pole is lifted once, through a car. The second car has to be re-waited for the pole to lift. When Set is called, the state becomes "available", but once a WaitOne request state is executed, the state becomes "unavailable" (this process does not require the Reset method to participate).

Pros: Provides the ability to communicate between threads, which can be used across processes.

Cons: Slower than user mode, mixed mode construction, slightly faster than mutex.

For more information on the use of ManualResetEvent and AutoResetEvent, please refer to "ManualResetEvent and AutoResetEvent Rapid Literacy".

Mixed Mode (Hybrid-mode)

ManualResetEventSlim was introduced in. Net 4.0 to improve performance. The following is the exact words of MSDN:

In the. NET Framework version 4, the System.Threading.ManualResetEventSlim class can be used for better performance when the wait time is expected to be very short, and when events do not cross process boundaries. When the wait event becomes signaled, ManualResetEventSlim uses a busy rotation for a short period of time. When the wait time is short, the overhead of the rotation is much less expensive than waiting with the wait handle. However, if the event does not become signaled during a certain period of time, the ManualResetEventSlim uses regular event-handling waits.

---"ManualResetEvent and ManualResetEventSlim"

The usage of ManualResetEventSlim is almost similar to that of ManualResetEvent, except that the place where the WaitOne was originally used should be replaced by Wait.

Pros: Provides the ability to communicate between threads.

Cons: cannot be used across processes, faster than kernel-mode constructs.

Summary

This article addresses synchronization issues between threads when two or more threads need to be executed in some order. If you encounter two threads in development that need to be executed in one order or another, you should consider using either ManualResetEvent or AutoResetEvent.

Series Catalogue

1. The opening is beneficial

2, Scenario One: This manger has a master

3, Scenario Two: Limited quantity, first-come first-served

4, Scenario Three: I let you move, you move again!

[Go] Thread synchronization