1. What is the design mode CSP of channel?

1.1 What is a CSP? What are the benefits of traditional shared memory?

  • CSP:3. Communicating: One way to communicate is to communicate with one another through channels. This also corresponds to a classic saying of golang communityInstead of communicating by sharing memory, you should share memory by communicating
  • What are the benefits of this design pattern (versus shared memory)?
    • Decoupling, through data redundancy to avoid programmers frequently direct operation of locks, reduce coding complexity
    • Facilitate distributed communication (currently not reflected in Golang Channel)

1.2 Compare the concurrency model Actor and CSP

  • What is an Actor?
    • The Actor model is a concurrent model, as opposed to the shared memory model, which shares nothing. All threads (or processes) collaborate through message-passing (mailboxes), called actors
  • Actor and CSP comparison diagram? The first picture is actor and the second is channel

  • What is the difference between the CSP model and the Actor model
    • In CSP communication, goroutines are uncoupled from channels and actors are coupled from mailboxes that pass messages
    • CSP communication is synchronous, while actors are asynchronous. Golang channels are optimized to support caching
    • Two Goroutines in CSP communication that communicate through channels are anonymous to each other because of channels, whereas instances of actors in actors are not
    • The CSP model guarantees orderality, while the Actor model does not. For example, when production is one and consumers are multiple

​

2. What is the underlying structure of a channel?

  • Runtime /chan.go runtime/chan.go
type hchan struct {
	qcount   uint           // total data in the queue
	dataqsiz uint           // size of the circular queue
	buf      unsafe.Pointer // points to an array of dataqsiz elements
	elemsize uint16
	closed   uint32
	elemtype *_type // element type
	sendx    uint   // send index
	recvx    uint   // receive index
	recvq    waitq  // list of recv waiters
	sendq    waitq  // list of send waiters

	// lock protects all fields in hchan, as well as several
	// fields in sudogs blocked on this channel.
	//
	// Do not change another G's status while holding this lock
	// (in particular, do not ready a G), as this can deadlock
	// with stack shrinking.
	lock mutex
}
Copy the code

3. What are the problems encountered in the use of channel? How to solve it?

3.1 wrote data to a closed channel, causing Panic

  • Solution 1: Write goroutineshi to close channels, not read channels
  • Solution 2: Block closure with sync.waitGroup when multiple groutine writes are encountered

3.2 If a cached channel is closed, data can still be read

  • To be compatible with this type of situation, it cannot be said that if a channel has been closed, there will be no data. The code is as follows
package main

import (
	"fmt"
	"testing"
	"time"
)


func OnlyRead(testCh <-chan string) {
	result, ok := <-testCh
	fmt.Println(result, ok) // the output is msg1 true
}

func TestChannel(t *testing.T) {

	testCh := make(chan string.5)
	testCh <- "msg1"
	close(testCh)
	go OnlyRead(testCh)
	time.Sleep(time.Second)

}
Copy the code

3.3 When a function writes and reads a channel, the complexity increases

  • Restrict read – only or write – only by passing the parameter as follows
package main

import (
	"fmt"
	"testing"
	"time"
)

func OnlyWrite(testCh chan<- string) {

	testCh <- "msg2"
}

func OnlyRead(testCh <-chan string) {
	for result := range testCh {
		fmt.Println(result, "= = = =")}}func TestChannel(t *testing.T) {

	testCh := make(chan string.2)
	testCh <- "msg1"
	go OnlyRead(testCh)
	go OnlyWrite(testCh)
	time.Sleep(time.Second * 1)
	close(testCh)

}
Copy the code

4. Reference links

CSP and actor differences:

  • ​www.quora.com/What-are-th…
  • ​Engineering.universe.com/introductio…