이러한 상황을 고려하십시오. 하나의 메인 goroutine과 10 개의 자회사 골 루틴이 있습니다. 모두가 channel에 액세스 할 수 있습니다. 메인 채널은 1000 숫자를이 채널에 보내고 보조 채널은 숫자를 읽습니다. 각 보조 goroutine이 정확하게 100 개의 숫자를 읽는다는 보장이 있습니까? 아니면이 수치는 일부 goroutine이 99 숫자와 101을 읽는 것처럼 다양 할 수 있습니까?채널을 통한 이동
아니요, 모든 goroutine의 런타임에 따라 다르며 goroutines가 CPU에 얼마나 잘 분산되어 있는지에 따라 달라 지므로 보장 할 수 없습니다.
흥미 롭다면 GoRoutines 일정이 잡힌 블로그 게시물 [여기] (https://rakyll.org/scheduler/)을 발견했습니다. –
버퍼없는 채널을 통한 goroutine 스케줄링을 통해 흥미로운 점은 채널이 순수하게 차단 메커니즘으로 사용된다는 것입니다. 즉, 값은 결코 채널로 전송되지 않으며 실제 "읽지"않습니다.
버퍼가없는 채널은 순전히 동기화 메커니즘으로 작동합니다. 채널에서 보내는 goroutine의 경우 "goroutine을 수신 할 준비가 될 때까지 잠자기"의 선을 따라 더 많이 작동하며 수신 goroutine의 경우 "goroutine 보낼 준비가되었습니다. "
이것은 송수신에 일종의 공정성 또는 분배 시스템이 내장되어 있지 않다는 것을 분명히해야합니다. 순전히 선착순이거나 또는 스케줄러의 현재로드에 따라 더 자유 롭습니다.
CSP 사고 방식에서는 이러한 구별이 불필요하며 설명이 사물을 명확하게하는 데 도움이되지 않습니다. 버퍼링되지 않은 채널은 데이터 이벤트가 흐르는 '정상적인'채널입니다. 버퍼링 된 채널에는 확장 된 동작이 있습니다. –
이것이 개념적으로 올바른 방식을 사용하는 방법이지만 데이터 이벤트 흐름은 파이프 나 큐를 생각 나게합니다. 이는 데이터 이벤트가 상대방의 상태와 관계없이 받아 들여질 것이라는 의미입니다. . 하지만 Go에서 버퍼링되지 않은 채널이 작동하는 방식은 아닙니다. –
보증이없는 이유는 무엇입니까? – tkausl
@ tkausl은 goroutine간에 작업을 균등하게 분배합니다. –
이러한 보증이 없을뿐만 아니라 정상적인 환경에서 발생할 것이라고 가정 할 이유가 없습니다. – Flimzy