Concurrency 101

Въпрос за мъфин #1

Колко памет се копира, когато подадем масив на функция?

Потенциално много. Копира се целия масив.

Въпрос за мъфин #2

Колко полета има една slice структура? Кои са те?

Три:
pointer
len
cap

Въпрос за мъфин #3

Възможно ли е map да има стойности от различен тип?

Не
Един map е от вида map[KeyType]ValueType

Въпрос за мъфин #4

Колко начина има да се създаде нова структура от тип Т? Кои са те?

Два:
x := new(T)
x := &T{}

Въпрос за мъфин #5

Колко памет заема една структура?

Сбора на паметта, нужна на нейните полета. Плюс падинг до края на машинната дума.
Без никакви допълнителни meta данни.

Какво ще говорим днес?

Конкурентност с/у Паралелизъм
Кратка история на многопроцесорното програмиране
go рутини
Споделяне чрез комуникация
channels

Магически паралелизъм?

Go е конкурентен
... следователно всичко ще работи паралелно! Yey!
Не е точно така! Може би бъркате дефинициите си.

Конкурентност

Набор от независими процеси

Паралелизъм

Изпълнение на различни неща едновременно
Свързани по между си или не

Конкурентност с/у Паралелизъм

Когато говорим за конкурентност говорим за структура
Когато говорим за паралелизъм става въпрос за изпълнение

Обяснение с малко повече gophers

Лекция на Rob Pike по въпроса:

blog.golang.org/concurrency-is-not-parallelism

Moore's law

А какво става, когато имаме много ядра?

IO-bound vs. CPU-bound

CPU-bound са програми, които главно зависят от време, прекарано в процесора
IO-bound са програми, които главно зависят от време, прекарано в чакане (мрежа, памет, диск)

Processes vs. Threads (Green & Native)

Три начина за конкурентност
Кой ще обясни разликите?

Подходи

Процеси
Нишки (два вида)
Актьори
Мега умни компилатори?

В C ползват вилици

#include <stdio.h>

int main()
{
    printf("before\n");
    if (fork())
        printf("parent\n");
    else
        printf("child\n");
    printf("both\n");
}

fork създава ново копие на програмата, която изпълняваме
Всички ресурси и променливи запазват стойността си в процеса-дете
След създаването на новия процес, всички промени са локални
Все едно клонираме хора, за да вършим повече работа едновременно

Синхронизация на вилици

#include <stdio.h>
#include <unistd.h>

int main()
{
    pid_t pid = fork();
    if (pid == 0) {
        execl("/bin/sleep", "/bin/sleep", "2", (char *) 0);
    } else {
        waitpid(pid, NULL, 0);
    }
    printf("done!\n");
    return 0;
}

execl спира изпълнението на текущия процес и зарежда друг
waitpid позволява на родителя да чака свършването на конкретно дете

Предимства и недостатъци на fork

Против:

Само за UNIX
Създаването на нов процес е бавно и паметоемко
Комуникацията между процеси е трудна - нямат обща памет
Копира се паметта на процеса

За:

Копира се паметта на процеса
Стабилност
Детето е независимо - ако омаже нещо, родителя няма да пострада

В Go се правим на модерни

Fork не се препоръчва
Имаме по - добър начин, за него след малко
Ако все пак искате чрез библиотеката syscall можете да вдигнете нов процес
Не го правете, ако нямате много сериозна причина

Нишки

Много нишки живеят в един и същи процес
Следователно имат достъп до една и съща памет
Глобалните променливи са общи за нишките
Създават се бързо и лесно
Това е концепция в операционните системи
Някои езици ги поддържат директно
Други ги скриват зад ниво на абстрактност

Нишки в C

void *ticker(void *x_void_ptr) {
    while (42) {
        sleep(1);
        printf("tick\n");
    }

    return NULL;
}

int main() {
    pthread_t ticker_thread;

    if(pthread_create(&ticker_thread, NULL, ticker, &x)) {
        fprintf(stderr, "Error creating thread\n");
        return 1;
    }

    if(pthread_join(ticker_thread, NULL)) {
        fprintf(stderr, "Error joining thread\n");
        return 2;
    }

    return 0;

Нишки в Python

def ticker():
    while 42:
        print("Tick!")
        time.sleep(1)

thread = threading.Thread(target=ticker)
thread.daemon = True
thread.start()

или

class TickerThread(threading.Thread):
    def run(self):
        while 42:
            print("Tick!")
            time.sleep(1)

thread = TickerThread()
thread.start()
# ...
thread.join()

Скучно

За да се съсредоточим върху това, което се опитваме да кажем ще дадем скучен пример.

package main

import (
	"fmt"
	"time"
)

func main() {
	boring("boring!")
}

func boring(msg string) {
    for i := 0; ; i++ {
        fmt.Println(msg, i)
        time.Sleep(1 * time.Second)
    }
}

За конкурентноста тайминга е важен. Нека е малко по - непредвидим.

Малко по - малко скучно

Ще сложим случайно време за сън.

package main

import (
	"fmt"
	"math/rand"
	"time"
)

func main() {
    boring("boring!")
}

func boring(msg string) {
    for i := 0; ; i++ {
        fmt.Println(msg, i)
        time.Sleep(time.Duration(rand.Intn(1e3)) * time.Millisecond)
    }
}

Скучната ни програма ще продължи да работи така до безкрайност. Като много скучна лекция, от която ви е неудобно да си тръгнете.

Да я игнорираме

Скучната програма не заслужава вниманието ни, нека не я чакаме.

С go пускаме функция нормално, но пускащия няма нужда чака приключването й.

Пускаме goroutine.

package main

import (
    "fmt"
    "math/rand"
    "time"
)

func main() {
    go boring("boring!")
}


func boring(msg string) {
	for i := 0; ; i++ {
		fmt.Println(msg, i)
		time.Sleep(time.Duration(rand.Intn(1e3)) * time.Millisecond)
	}
}

Когато main приключи програмата спира.

Да я игнорираме малко по - малко

package main

import (
    "fmt"
    "math/rand"
    "time"
)

func main() {
    go boring("boring!")
    fmt.Println("Listening.")
    time.Sleep(2 * time.Second)
    fmt.Println("You are way too boring. I am leaving.")
}


func boring(msg string) {
	for i := 0; ; i++ {
		fmt.Println(msg, i)
		time.Sleep(time.Duration(rand.Intn(1e3)) * time.Millisecond)
	}
}

Изпълнявахме main и скучната функция едновременно.

С края на main дойде и края на скучната функция.

Какво е Goroutine

Независимо изпълняваща се функция
Практически безплатни са за създаване от към памет и процесорно време. Може да имате стотици хиляди в един процес
Не е thread
Зелени нишки
Има умен scheduler, който мапва горутини към OS нишки
Но ако мислите за тях като за много евтини нишки, няма да сте далеч от истината
Дизайна на езика и особено go рутините са много повлияни от Communicating sequential processes на C. A. R. Hoare

Вдъхновено от

Последните няколко примера са безсрамно присвоени от лекция на Rob Pike. Интересна е, препоръчваме я.

www.youtube.com/watch?v=f6kdp27TYZs

А сега да се върнем към нишки и goroutines

Проблеми, свързани с нишки

От това, че имат една и съща памет, следва, че могат да достъпват едни и същи променливи

int i = 0

thread1 { i++ }
thread2 { i++ }

wait { thread1 } { thread2 }
print i

Тук i накрая може да бъде 1 или 2.

Критични секции

Части от кода, които могат да бъдат изпълнени само от една нишка/процес в даден момент, се наричат критични секции
Те са критична част от многозадачното програмиране
Има много похвати за реализирането на критични секции.
STM, Semaphors & Co., Message passing, Actors

В Go имаме Semaphors и Message passing

Communicate by sharing vs. Share by communicating

Channels

Вграден тип, който се използва за комуникация между две горутини.
Може да се използва и за синхронизация
За тях има специален синтаксис

Употреба на канали

Инстанцират се с make
Подава се типа, който ще се пренася от канала

ch := make(chan uint64)

Могат да бъдат буферирани и небуферирани

ch := make(chan []string, 100)

В канал може да се изпраща и от него може да се получава

ch <- 64
read := <-ch

Когато изпращаме или получаваме, това може да блокира

IO в канал

Операциите по изпращане и получаване се изпълняват с оператора <-

chan <- стойност изпраща по канала
променлива = <-chan получава от канала

Канал може да бъде затворен

close(ch)

Повече не може да бъде отворен
Четенето в него никога не блокира
... като връща нулевата стойност за типа
Писането в него води до паника

Създаване на канали

Небуфериран канал за пренасяне на цели числа:

intChannel := make(chan int)

Буфериран канал за пренасяне на стрингове:

stringBufferedChannel := make(chan string, 5)

Канал само за четене:

readOnlyChannel := make(<-chan int)

Канал само за писане:

writeOnlyChannel := make(chan<- int)

Каналите са първокласни обекти в Go

По канал може да пренасяте канал

c := make(chan chan int)

Каналите могат да се подават като параметри на функции

func doSomething(input <-chan string) {}

Функциите могат да връщат канали като резултат.

func doSomethingElse() chan string {
  result := make(chan string)
  return result
}

nil channel

Никога не използвайте неинициализиран канал!

Писането в него блокира завинаги

package main

func main() {
    var c chan string
    c <- "ping" // deadlock
}

Четенето от него... блокира завинаги

package main

import "fmt"

func main() {
    var c chan string
    fmt.Println(<-c) // deadlock
}

Пример

c := make(chan int)

go func() {
    list.Sort()
    c <- 1
}()

doSomethingForAWhile()
<-c

Не използвайте int или bool ако просто използвате канала за синхронизация.
Използвайте struct{} за целта - безплатно от гледна точка на памет.

По-сложен пример

var sem = make(chan struct{}, MaxOutstanding)

func handle(r *Request) {
    <-sem
    process(r)
    sem <- struct{}{}
}

func init() {
    for i := 0; i < MaxOutstanding; i++ {
        sem <- struct{}{}
    }
}

func Serve(queue chan *Request) {
    for {
        req := <-queue
        go handle(req)
    }
}

Deadlock

func main() {
     c := make(chan int)
     c <- 42
     val := <-c
     println(val)
}

Затваряне на канали

package main

import "fmt"

func main() {
    ch := make(chan string)

    go func(output chan string) {
        for i := 0; i < 5; i++ {
            output <- fmt.Sprintf("sending N=%d", i)
        }
        close(output)
    }(ch)

    for i := 0; i < 7; i++ {
        val, ok := <-ch
        fmt.Printf("Recieved: %#v, %#v\n", val, ok)
    }

    ch <- fmt.Sprintf("where is your towel?")
}

range

Помните ли как ви казахме, че range е нещо супер яко?

Може да чете и от канали
Блокира, докато не получи следващата стойност
Излизаме от for, когато каналът бъде затворен

for val := range ch {
    fmt.Printf("Recieved: %#v\n", val)
}

Communicating sequential processes

by Tony Hoare

usingcsp.com/cspbook.pdf