управление состоянием горутин
This commit is contained in:
parent
be57797702
commit
80e08633e1
@ -36,7 +36,7 @@ WaitGroups
|
||||
Ограничение скорости (Rate Limiting)
|
||||
Атомарные счетчики (Atomic Counters)
|
||||
Мьютексы (Mutexes)
|
||||
Stateful Goroutines
|
||||
Управление состоянием горутин (Stateful Goroutines)
|
||||
Sorting
|
||||
Sorting by Functions
|
||||
Panic
|
||||
|
@ -1,11 +1,11 @@
|
||||
// In the previous example we used explicit locking with
|
||||
// [mutexes](mutexes) to synchronize access to shared state
|
||||
// across multiple goroutines. Another option is to use the
|
||||
// built-in synchronization features of goroutines and
|
||||
// channels to achieve the same result. This channel-based
|
||||
// approach aligns with Go's ideas of sharing memory by
|
||||
// communicating and having each piece of data owned
|
||||
// by exactly 1 goroutine.
|
||||
// В предыдущем примере мы использовали явную блокировку
|
||||
// с [мьютексами](mutexes) для синхронизации доступа к
|
||||
// общему состоянию между несколькими горутинами. Другой
|
||||
// вариант - использовать встроенные функции синхронизации
|
||||
// для горутин и каналов для достижения того же результата.
|
||||
// Этот подход, основанный на каналах, согласуется с идеями
|
||||
// Go о совместном использовании памяти путем обмена
|
||||
// данными и владения каждой частью данных ровно 1 горутиной.
|
||||
|
||||
package main
|
||||
|
||||
@ -16,6 +16,14 @@ import (
|
||||
"time"
|
||||
)
|
||||
|
||||
// В этом примере наше состояние будет принадлежать
|
||||
// единственной горутине. Это гарантирует, что данные
|
||||
// никогда не будут повреждены при одновременном доступе.
|
||||
// Чтобы прочитать или записать это состояние, другие
|
||||
// горутины будут отправлять сообщения горутин-владельцу
|
||||
// и получать соответствующие ответы. Эти `структуры`
|
||||
// `readOp` и `writeOp` инкапсулируют эти запросы и
|
||||
// способ, которым владеет горутина-ответчик.
|
||||
// In this example our state will be owned by a single
|
||||
// goroutine. This will guarantee that the data is never
|
||||
// corrupted with concurrent access. In order to read or
|
||||
@ -36,25 +44,26 @@ type writeOp struct {
|
||||
|
||||
func main() {
|
||||
|
||||
// As before we'll count how many operations we perform.
|
||||
// Как и прежде, мы посчитаем, сколько операций мы
|
||||
// выполняем.
|
||||
var readOps uint64
|
||||
var writeOps uint64
|
||||
|
||||
// The `reads` and `writes` channels will be used by
|
||||
// other goroutines to issue read and write requests,
|
||||
// respectively.
|
||||
// Каналы `чтения` и `записи` будут использоваться
|
||||
// другими горутинами для выдачи запросов на чтение
|
||||
// и запись соответственно.
|
||||
reads := make(chan readOp)
|
||||
writes := make(chan writeOp)
|
||||
|
||||
// Here is the goroutine that owns the `state`, which
|
||||
// is a map as in the previous example but now private
|
||||
// to the stateful goroutine. This goroutine repeatedly
|
||||
// selects on the `reads` and `writes` channels,
|
||||
// responding to requests as they arrive. A response
|
||||
// is executed by first performing the requested
|
||||
// operation and then sending a value on the response
|
||||
// channel `resp` to indicate success (and the desired
|
||||
// value in the case of `reads`).
|
||||
// Эта горутина, которой принадлежит состояние, она же
|
||||
// является картой, как в предыдущем примере, но теперь
|
||||
// является частной для горутины с сохранением состояния.
|
||||
// Она постоянно выбирает каналы `чтения` и `записи`,
|
||||
// отвечая на запросы по мере их поступления. Ответ
|
||||
// выполняется, сначала выполняя запрошенную операцию,
|
||||
// а затем отправляя значение по каналу `resp`,
|
||||
// соответственно, чтобы указать успешность (и
|
||||
// ребуемое значение в случае `reads`).
|
||||
go func() {
|
||||
var state = make(map[int]int)
|
||||
for {
|
||||
@ -68,11 +77,11 @@ func main() {
|
||||
}
|
||||
}()
|
||||
|
||||
// This starts 100 goroutines to issue reads to the
|
||||
// state-owning goroutine via the `reads` channel.
|
||||
// Each read requires constructing a `readOp`, sending
|
||||
// it over the `reads` channel, and the receiving the
|
||||
// result over the provided `resp` channel.
|
||||
// Запускаем 100 горутин для выдачи операций чтения
|
||||
// в горутину владеющую состоянием, через канал `reads`.
|
||||
// Каждое чтение требует создания `readOp`, отправки
|
||||
// его по каналу `reads` и получения результата по
|
||||
// `resp` каналу.
|
||||
for r := 0; r < 100; r++ {
|
||||
go func() {
|
||||
for {
|
||||
@ -87,8 +96,7 @@ func main() {
|
||||
}()
|
||||
}
|
||||
|
||||
// We start 10 writes as well, using a similar
|
||||
// approach.
|
||||
// Так же делаем 10 записей.
|
||||
for w := 0; w < 10; w++ {
|
||||
go func() {
|
||||
for {
|
||||
@ -104,10 +112,10 @@ func main() {
|
||||
}()
|
||||
}
|
||||
|
||||
// Let the goroutines work for a second.
|
||||
// Дадим горутинам отработать 1 секунду
|
||||
time.Sleep(time.Second)
|
||||
|
||||
// Finally, capture and report the op counts.
|
||||
// Наконец, выводим данные счетчиков
|
||||
readOpsFinal := atomic.LoadUint64(&readOps)
|
||||
fmt.Println("readOps:", readOpsFinal)
|
||||
writeOpsFinal := atomic.LoadUint64(&writeOps)
|
||||
|
@ -1,15 +1,16 @@
|
||||
# Running our program shows that the goroutine-based
|
||||
# state management example completes about 80,000
|
||||
# total operations.
|
||||
# Запуск нашей программы показывает, что управление
|
||||
# состоянием на основе горутин завершает около
|
||||
# 80 000 операций.
|
||||
$ go run stateful-goroutines.go
|
||||
readOps: 71708
|
||||
writeOps: 7177
|
||||
|
||||
# For this particular case the goroutine-based approach
|
||||
# was a bit more involved than the mutex-based one. It
|
||||
# might be useful in certain cases though, for example
|
||||
# where you have other channels involved or when managing
|
||||
# multiple such mutexes would be error-prone. You should
|
||||
# use whichever approach feels most natural, especially
|
||||
# with respect to understanding the correctness of your
|
||||
# program.
|
||||
# Для этого конкретного случая подход, основанный на
|
||||
# горутине, был немного более сложным, чем подход,
|
||||
# основанный на мьютексе. Это может быть полезно в
|
||||
# некоторых случаях, например, когда задействованы
|
||||
# другие каналы или при управлении несколькими такими
|
||||
# мьютексами могут возникать ошибки. Вы должны
|
||||
# использовать тот подход, который кажется вам наиболее
|
||||
# естественным, особенно в отношении понимания
|
||||
# правильности вашей программы.
|
Loading…
x
Reference in New Issue
Block a user