Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you about how to achieve the sequential output of shared variables in Thread and goroutine. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

Background

Recently, I have been looking at some of the underlying implementations of go. The most impressive one is that Rob Pike, one of the creators of the go language, said that instead of communicating through shared memory, we should share memory through communication. The corresponding implementation of the second half of the sentence is channel, which uses channels to transfer data between multiple goroutine. See here, I can not help but have a question, for the transfer of stateless data, through the channel to ensure the security of concurrency between data, but I now have a critical area or shared variables, there is multi-thread concurrent access. How does the Go protocol control data concurrency security? Are there any other tricks? With this in mind, let's take a look at how Go ensures concurrent access to shared variables in the critical section.

Let's use a classic problem to verify how threads and co-programs are solved respectively.

There are three threads / coroutines that complete the following tasks: 1 threading / co-programming printing 1 min2 threads / co-program printing 2 threads / 3 threads / co-program printing 3, printing 15 times alternately. Output: 123123123123123

Java implementation

How does java solve this problem? First of all, it is required to output in turn, then the above problem can be achieved as long as the threads wait for each other or are in step.

How to achieve the same pace? There are at least three ways I know, and here are three implementations to show how Java threads control concurrent access to shared variables in the critical section.

Synchronized implementation

The mutex problem is solved through Synchronized; (wait/notifyAll) the wait-notification mechanism controls the execution rhythm between multiple threads. The implementation is as follows:

Public class Thread123 {

Public static void main (String [] args) throws InterruptedException {

Thread123 testABC = new Thread123 ()

Thread thread1 = new Thread (new Runnable () {

@ Override

Public void run () {

Try {

For (int I = 0; I < 5; iTunes +) {

TestABC.printA ()

}

} catch (InterruptedException e) {

E.printStackTrace ()

}

}

});

Thread thread2 = new Thread (new Runnable () {

@ Override

Public void run () {

Try {

For (int I = 0; I < 5; iTunes +) {

TestABC.printB ()

}

} catch (InterruptedException e) {

E.printStackTrace ()

}

}

});

Thread thread3 = new Thread (new Runnable () {

@ Override

Public void run () {

Try {

For (int I = 0; I < 5; iTunes +) {

TestABC.printC ()

}

} catch (InterruptedException e) {

E.printStackTrace ()

}

}

});

Thread1.start ()

Thread2.start ()

Thread3.start ()

Thread1.join ()

Thread2.join ()

Thread3.join ()

}

Int flag = 1

Public synchronized void printA () throws InterruptedException {

While (flag! = 1) {

This.wait ()

}

System.out.print (flag)

Flag = 2

This.notifyAll ()

}

Private synchronized void printB () throws InterruptedException {

While (flag! = 2) {

This.wait ()

}

System.out.print (flag)

Flag = 3

This.notifyAll ()

}

Private synchronized void printC () throws InterruptedException {

While (flag! = 3) {

This.wait ()

}

System.out.print (flag)

Flag = 1

This.notifyAll ()

}

}

If you see this implementation, you may have the following two questions:

Why use notifyAll instead of notify?

"

There is actually a difference between the two. Notify randomly notifies one thread in the waiting queue, while notifyAll notifies all threads in the waiting queue. Maybe our first feeling is that even if we use notifyAll, only one thread can actually execute, but in multithreaded programming, the so-called feeling is risky, because some threads may never be awakened, which leads to execution even if the conditions are met, so unless you know very well that your thread executes the logic, in general, do not use notify. If you are interested, the above example can be tested and you can see why you are not recommended to use notify.

"

Why use while loops instead of the lighter if?

"

The reason for taking advantage of while is fundamentally the programming paradigm in java, and while is required whenever wait waiting is involved. The reason is that when wait returns, it is possible to determine that the condition has changed, so you need to recheck whether the condition is met.

"Lock implementation

Solve the problem of mutual exclusion between multiple threads through Lock; (await/signal) solve the synchronization between threads, of course, this is the same as the previous effect.

Public class Test {

/ / the printing method is the same as the previous one, but it is not given here.

Private int flag = 1

Private Lock lock = new ReentrantLock ()

Private Condition condition1 = lock.newCondition ()

Private Condition condition2 = lock.newCondition ()

Private Condition condition3 = lock.newCondition ()

Private void print1 () {

Try {

Lock.lock ()

While (flag! = 1) {

Try {

This.condition1.await ()

} catch (InterruptedException e) {

E.printStackTrace ()

}

}

System.out.print ("A")

Flag = 2

This.condition2.signal ()

} finally {

Lock.unlock ()

}

}

Private void print2 () {

Try {

Lock.lock ()

While (flag! = 2) {

Try {

This.condition2.await ()

} catch (InterruptedException e) {

E.printStackTrace ()

}

}

System.out.print ("B")

Flag = 3

This.condition3.signal ()

} finally {

Lock.unlock ()

}

}

Private void print3 () {

Try {

Lock.lock ()

While (flag! = 3) {

Try {

This.condition3.await ()

} catch (InterruptedException e) {

E.printStackTrace ()

}

}

System.out.print ("C")

Flag = 1

This.condition1.signal ()

} finally {

Lock.unlock ()

}

}

Semaphore implementation

Semaphore acquisition and return mechanism to ensure the concurrency security of shared data, the following is part of the core code

/ / semaphores starting with S1. The initial number of semaphores is 1.

Private static Semaphore S1 = new Semaphore (1)

/ / S2 and S3 semaphores, which starts after S1 is completed, and the initial number of signals is 0

Private static Semaphore S2 = new Semaphore (0)

Private static Semaphore S3 = new Semaphore (0)

Static class Thread1 extends Thread {

@ Override

Public void run () {

Try {

For (int I = 0; I < 10; iTunes +) {

S1.acquire (); / S1 gets the signal execution, S1 semaphore minus 1, when S1 is 0, the semaphore cannot be obtained again

System.out.print ("1")

S2.release (); / / S2 release signal, S2 semaphore plus 1 (initial 0), you can get B semaphore

}

} catch (InterruptedException e) {

E.printStackTrace ()

}

}

}

In fact, in addition to the above methods, using CountDownLatch to achieve multiple threads waiting for each other should also be solved, there are not too many examples here.

Go implementation

In the implementation process of using Go, three knowledge points are mainly used. 1. Three goroutine have been enabled to operate on shared variables. 2. Three condition variables generated by a mutex control the three cooperators. 3. The purpose of using signChannel is to prevent goroutine from running prematurely.

Package main

Import (

"log"

"sync"

)

Func main () {

/ / declare shared variables

Var flag = 1

/ / declare mutex

Var lock sync.RWMutex

/ / three condition variables to control the execution frequency of the three co-programs

Cnd1: = sync.NewCond (& lock)

Cnd2: = sync.NewCond (& lock)

Cnd3: = sync.NewCond (& lock)

/ / create a channel to control goroutine to stop running prematurely

SignChannel: = make (chan struct {}, 3)

/ / maximum number of cycles

Max: = 5

Go func (max int) {

/ / release after the completion of this goroutine execution

Defer func () {

SignChannel

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.