DEV Community: Furkan Aksoy

Chain of Responsibility Pattern in Go

Furkan Aksoy — Tue, 21 May 2024 19:00:07 +0000

The Chain of Responsibility Pattern is a behavioral design pattern that allows an object to pass a request along a chain of handlers. The chain of handlers can either handle the request or pass it on to the next handler in the chain. The request is passed along the chain until it is handled or until it reaches the end of the chain.

In this article, we will explore the Chain of Responsibility Pattern in Go. We will create a simple example to demonstrate how the pattern works and how it can be implemented in Go.

The Chain of Responsibility Pattern is commonly used in scenarios where there are multiple objects that can handle a request, and the sender of the request does not know which object will handle the request. Examples of such scenarios include event handling, logging, and error handling.

Example

Let's create a simple example to demonstrate the Chain of Responsibility Pattern in Go. In this example, chain will be responsible to validate the request, printing the error logs and handling the request itself.

package service

import "fmt"

type Service interface {
    HelloWorld(name string) (string, error)
}

type service struct {}

func (s service) HelloWorld(name string) (string, error) {
    return fmt.Sprintf("Hello World from %s", name)
}

type validator struct {
    next Service
}

func (v validator) HelloWorld(name string) (string, error) {
    if len(name) <= 3 {
        return "", fmt.Errorf("name length must be greater than 3")
    }

    return v.next(name)
}

type logger struct {
    next Service
}

func (l logger) HelloWorld(name string) (string, error) {
    res, err := l.next(name)

    if err != nil {
        fmt.Println("error:", err)
        return res, err
    }

    fmt.Println("HelloWorld method executed successfuly")
    return res, err
}

func New() Service {
    return logger{
        next: validator {
            next: service{}
        }
    }
}

package main

import (
    "fmt"
    "service"
)

func main() {
    s := service.New()

    res, err := s.HelloWorld("john")
    fmt.Println(res, err) // Hello World from john

    res, err := s.HelloWorld("joh")
    fmt.Println(res, err) // name length must be greater than 3 
}

In this example, we have created a simple service that implements the Service interface. The Service interface defines a method HelloWorld that takes a name as an argument and returns a greeting message.

We have also created two additional structs validator and logger that implement the Service interface. The validator struct validates the length of the name and returns an error if the length is less than or equal to 3. The logger struct prints the error logs and the success message when the HelloWorld method is executed successfully.

The New function creates a chain of handlers by chaining the validator and logger structs with the service struct. The service struct is the last handler in the chain and handles the request if it passes the validation.

What is next field in this example?

The next field in the validator and logger structs is used to chain the handlers. The next field holds the next handler in the chain. When the HelloWorld method is called on a handler, it calls the HelloWorld method on the next handler in the chain using the next field.

Conclusion

In this article, we explored the Chain of Responsibility Pattern in Go. We created a simple example to demonstrate how the pattern works and how it can be implemented in Go. I hope this article helps you understand the Chain of Responsibility Pattern and how it can be used in your projects. Happy coding!

Functional Options Pattern in Go

Furkan Aksoy — Sun, 19 May 2024 03:57:14 +0000

Introduction

In Go, the Functional Options pattern is a powerful technique that allows developers to provide flexible and customizable behavior to functions or methods by using functional options as arguments. This pattern is commonly used in Go libraries and frameworks to provide a clean and concise API for users.

What is the Functional Options Pattern?

The Functional Options pattern is a design pattern that leverages the power of higher-order functions and closures in Go to provide a flexible way of configuring objects or functions. Instead of using a large number of parameters or flags, the Functional Options pattern allows developers to pass in a series of functions, each of which configures a specific aspect of the object or function.

The Functional Options Pattern in Go addresses several challenges related to configuration and initialization of objects:

Growing Number of Parameters: Traditional function signatures can become unwieldy as the number of parameters increases. The functional options pattern allows you to add new options without changing the function signature or breaking existing code.
Readability: When a function takes multiple parameters, especially of the same type, it can be hard to remember the order and meaning of each. With functional options, each option is clearly labeled and self-explanatory, enhancing code readability.
Default Values: The functional options pattern allows you to easily provide default values for your options. If an option is not provided when the function is called, the default value is used.
Optional Parameters: In some cases, you might want to make some parameters optional. The functional options pattern allows you to do this easily, providing a flexible interface.
Encapsulation and Validation: Each option is a function that can contain its own validation logic. This allows you to encapsulate the logic for each option and keep your main function clean and simple.

How does it work?

The Functional Options pattern works by defining a function type that represents an option. This function type takes a pointer to the object or function being configured as its argument and modifies it accordingly. The object or function being configured typically has a corresponding struct type that holds the configuration options as fields.

To use the Functional Options pattern, developers can define a variadic function that takes a series of option functions as arguments. Inside this function, the options are applied one by one to the object or function being configured.

What is variadic function?

A variadic function in Go is a function that can be called with any number of trailing arguments. This means you can pass as many arguments as you want into the variadic function.

The syntax for declaring a variadic function involves using an ellipsis ... before the type of the last parameter. The function receives this as a slice of the type.

Here's an example:

package main

import "fmt"

// This is a variadic function that accepts any number of integers
func sum(nums ...int) {
    fmt.Print(nums, " ")
    total := 0
    for _, num := range nums {
        total += num
    }
    fmt.Println(total)
}

func main() {
    sum(1, 2)
    sum(1, 2, 3)
    nums := []int{1, 2, 3, 4}
    sum(nums...)
}

In this example, sum is a variadic function that takes any number of int arguments. In the main function, we call sum with different numbers of arguments.

Example

Let's illustrate the Functional Options pattern with an example. Suppose we have a Server struct that represents an HTTP server in Go. We want to provide users with the ability to configure various aspects of the server, such as the port it listens on, the timeout duration, and whether to enable logging.

First, we define the Server struct:

package main

import "fmt"

type Server struct {
    Host     string
    Port     int
    Protocol string
    Timeout  int
}

type ServerOption func(*Server)

func WithHost(host string) ServerOption {
    return func(s *Server) {
        s.Host = host
    }
}

func WithPort(port int) ServerOption {
    return func(s *Server) {
        s.Port = port
    }
}

func WithProtocol(protocol string) ServerOption {
    return func(s *Server) {
        s.Protocol = protocol
    }
}

func WithTimeout(timeout int) ServerOption {
    return func(s *Server) {
        s.Timeout = timeout
    }
}

func NewServer(options ...ServerOption) *Server {
    server := &Server{
        Host:     "localhost",
        Port:     8080,
        Protocol: "http",
        Timeout:  30,
    }

    for _, option := range options {
        option(server)
    }

    return server
}

func main() {
    server := NewServer(
        WithHost("example.com"),
        WithPort(9000),
        WithProtocol("https"),
        WithTimeout(60),
    )

    fmt.Printf("Server: %+v\n", server)
}

[TR] Golang - Context Nedir?

Furkan Aksoy — Thu, 30 Nov 2023 06:55:26 +0000

Golang - Context Nedir?

Merhaba, uzun süredir haşır neşir olduğum go context ile ilgili hem Türkçe kaynağın az olması, hem de kendi bilgilerimi pekiştirme amacıyla bu içeriği hazırlamak istedim. Umarım faydalı olur, keyifli okumalar.

Eğer Go ile bir web framework, routine, veritabanı bağlantısı, HTTP isteği vs gibi bir işlemle haşır neşir olduysanız, fonksiyonların içinde context.Context diye bir parametre mutlaka görmüşssünüzdür. Bazı framework'ler veya kütüphaneler bu context'in çevresini sararak kendi context'lerini oluşturabilir pek tabii. Fakat işlev 3 aşağı 5 yukarı aynıdır.

Context 101

Örnek: İptal Sinyali

Şöyle bir senaryomuz düşünelim; Veritabanına sorgu yapan bir fonksiyonumuz var. Bu fonksiyon çağırıldığında sorgu atılırken bir problem oldu ve çok fazla zaman aldı. Eğer bir sorgu 2 saniyeden fazla sürerse iptal olması gerekiyor. Bir diğer deyişle 2 saniye sonra bizim bu fonksiyona bir iptal et sinyali yollamamız gerekiyor. İşte bu durumda yardımımıza context yapısı koşuyor

Örnek: İstek Tabanlı Veriler

Bir web servisimiz ve 1 endpointimiz var. Fakat bu endpointimize gelen istekte bu isteğin hangi kullanıcı tarafından yapıldığını bilmek istiyoruz. Bu yüzden endpointimizin önüne bir middleware yazmaya karar verdik. Bu middleware istekte gelen token'ı parse edip kullanıcı bilgilerini endpoint'e iletmekle görevli.

Bu senaryoda da yardımımıza context yapısı koşuyor. Servisimize istek ilk geldiğinde bir context oluşuyor ve bu context bir sonra çalışcak olan fonksiyona yani middleware'e geçiliyor. Middleware içinde kullanıcı bilgileri context'e ekleniyor. Sonrasında da yine aynı context endpoint'e iletiliyor. Bu sayede endpoint içinde kullanıcı bilgilerini context üzerinden çekebiliyoruz.

Uzun lafın kısası Google context paketi için şöyle bir açıklama yapıyor:

Context paketi; istek tabanlı verileri, iptal sinyallerini, deadline bilgilerini bir API kapsamı içindeki tüm fonksiyonlara, goroutine'lere geçirebilmek için tasarlandı.

Context'e Yakından Bakış

type Context interface {
        // Done metodu, context tamamlandığında veya zaman aşımına uğradığında
    // kapanan bir channel döndürür.
    Done() <-chan struct{}

    // Err metodu, context'in neden kapandığını anlatan bir error döndürür.
    // Genellikle Done kanalı kapandıktan sonra bunu kullanırız.
    Err() error

    // Deadline metodu, eğer context herhangi bir deadline'a sahipse deadline zamanını döndürür.
    // `ok` değeri context bir deadline'a sahipse true, değilse false olur.
    Deadline() (deadline time.Time, ok bool)

    // Value metodu, context'in içerisinde saklanan bilgilere ulaşmak için kullanılır.
    Value(key interface{}) interface{}
}

Context'in içinde bulunan metodlar eşzamanlı olarak ayrı ayrı goroutine'lerde kullanılmaya uygundur. Bir context'i alıp birden fazla fonksiyon, goroutine vb yapıların içine yollayıp, bunların hepsine aynı anda iptal sinyali yollayabilirisiniz.

Yukarıda context'i tanımladık ve context'in eşzamanlı işlemlerde kullanılmasının uygun olduğunu söyledik. Fakat burada dikkat etmemiz gereken bir nokta var. Context içerisinde veri saklayabiliyoruz ve bu verilerin kontrolü bize ait. İçeri koyduğumuz veriler de eşzamanlı kullanıma uygun olmalı.

Hazır Context Tipleri

Background

Background context'i Go içinde tanımlı bulunan context.Background() içinde bir değer bulundurmayan, deadline'ı olmayan ve iptal edilemeyen bir context'tir. Aslında boş bir context'tir. Yeni üreteceğimiz contextler'de taban olarak kullanılır.

Go kodu içinde ise aşağıdaki gibi tanımlanmıştır.

type emptyCtx int

func (*emptyCtx) Deadline() (deadline time.Time, ok bool) {
    return
}

func (*emptyCtx) Done() <-chan struct{} {
    return nil
}

func (*emptyCtx) Err() error {
    return nil
}

func (*emptyCtx) Value(key interface{}) interface{} {
    return nil
}

background = new(emptyCtx)

func Background() Context {
    return background
}

TODO

TODO context'i yapı itibariyle background ile aynıdır. Aralarında anlamsal bi fark vardır. context.TODO() ile okuyucuya:

Buraya anlamlı bir context gelecek, şu an bu context'in ne olduğunu konusunda emin değilim ya da bu context'i sen belirlemelisin

mesajını vermiş oluyoruz.

Context Oluşturma

Yeni bir context sadece mevcut bir context üzerinden oluşturalabilir. Bunu bir ağaç yapısı gibi hayal edebiliriz.

Yukarıdaki ağaç yapısında C1, C2, C3, C4, C5 bizim contextlerimiz. C3 C2'den, C2 C1'den oluşturulmuş. Aynı şekilde C5 C4'den, C4 ise C1 den oluşturulmuş. Burada önemli olan bilgi ise şu:

Bir context iptal edildiğinde (cancel), o context kullanılarak oluşturulmuş tüm contextler iptal olur.

Yukarıdaki örnekten yola çıkacak olursak, C2'yi iptal ettiğimiz zaman otomatik olarak C3 iptal olur.

Context ile ilgili bütün işlemlerimizi context paketini kullanarak yapıyoruz. Bu paket içinde yeni contextler oluşturmak için bazı fonksiyonlar var. Şimdi bunları inceleyelim.

func WithCancel(parent Context) (ctx Context, cancel CancelFunc)

WithCancel içine verdiğimiz context'den yeni bir context üretir. Aynı zamanda bu context'i iptal edebilmemiz için bir fonksiyon döndürür. Bu fonksiyon çağırıldığı zaman yeni oluşturulan context iptal edilir.

func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc)

WithTimeout içine verdiğimiz context'den yeni bir context üretir. Aynı zamanda yeni oluşturulan context'i iptal edebilmemiz için bir fonksiyon döndürür. Bu kısma kadar yaptığı işlem WithCancel ile aynı. Aradaki tek fark timeout parametresi. timeout parametresiyle birlikte yeni oluşturulacak context'in ömrünü belirlemiş oluyoruz. Örneğin timeout değeri olarak 30 saniye verirsek, yeni oluşturulan context 30 saniye sonra iptal olacaktır.

func WithDeadline(parent Context, d time.Time) (Context, CancelFunc)

WithDeadline 'i WithTimeout gibi düşünebiliriz. WithTimeout ie yeni oluşturalacak context'in ne kadar süre yaşayacağını belirtirken, WithDeadline ile yeni oluşturalacak context'in ne zamana kadar yaşayacağını belirtiriz.

func WithValue(parent Context, key interface{}, val interface{}) Context

WithValue içine verdiğimiz context'den yeni bir context üretir. Aynı zamanda yeni üretilen context'in içine key ve val yerine verdiğimiz değerleri koyar. Bu sayede context içinde bilgi saklayabiliriz.

`Cancel` Fonksiyonu

Yukarıdaki örneklerin hemen hemen hepsinde yeni bir context oluşturduktan sonra elimizde Cancel fonksiyonu oluyor. Bu Cancel fonksiyonu ile oluşturulan yeni context'i iptal edebiliyoruz. Buradaki standart ise context'le işimiz bittiğinde o context'i iptal etmektir.
Context iptal edildiği zaman o context'e atanan bütün kaynaklar serbest kalır. Bu nedenle işimiz bittiğinde context'i iptal etmeyi unutmamalıyız.

ctx, cancel := context.WithCancel(context.Background())
defer cancel() // işimiz bittiğinde context'i iptal ediyoruz. İptal ettiğimiz zaman `ctx` kullanılarak üretilen bütün context'ler iptal olur.

Kod Örnekleri

Context - İptal

Playground

func a(ctx context.Context) {
    fmt.Println("a çalışmaya başladı")

    select {
    case <-time.After(1 * time.Second): // işlemler 1 saniye sürüyor
        fmt.Println("a çalışmasını bitirdi")
    case <-ctx.Done():
        fmt.Println("context iptal edildi")
    }
}

func main() {
    ctx, cancel := context.WithCancel(context.Background())

    go a(ctx) // a()'yı ayrı bi goroutine içinde başlattık.

    time.Sleep(500 * time.Millisecond) // context'i iptal etmeden önce 500ms uyuyoruz.
    cancel()                           // context'i iptal ediyoruz.

  time.Sleep(1 * time.Second)        // a()'nın çıktısını görebilmek için biraz bekliyoruz.
  fmt.Println("program sonlandı")
}

>> a çalışmaya başladı
>> context iptal edildi
>> program sonlandı

Context - Zaman Aşımı

Playground

func a(ctx context.Context) {
    fmt.Println("a çalışmaya başladı")

    select {
    case <-time.After(2 * time.Second): // işlemler 2 saniye sürüyor.
        fmt.Println("a çalışmasını bitirdi")
    case <-ctx.Done():
        fmt.Println("context iptal edildi")
    }
}

func main() {
    // 1 saniye sonra otomatik olarak iptal olacak bir context oluşturduk.
    ctx, cancel := context.WithTimeout(context.Background(), 1 * time.Second)
    defer cancel()

    go a(ctx) // a()'yı ayrı bi goroutine içinde başlattık.

    time.Sleep(5 * time.Second) // Sonuçları görebilmek için biraz uyuyoruz.
    fmt.Println("program sonlandı")
}

>> a çalışmaya başladı
>> context iptal edildi
>> program sonlandı

Context - Bilgi Gömmek

Playground

func a(ctx context.Context) {
    fmt.Println("a çalışmaya başladı")

    select {
    case <-ctx.Done():
        fmt.Println("context iptal edildi")
    default:
        if yeniDeger := ctx.Value("YeniDeger"); yeniDeger != nil {
            fmt.Println("context içinden okunan değer:", yeniDeger)
        }
    }
}

func main() {
    // Context'in içine bilgi gömdük, yeni bir context oluşturduk. 
    ctx := context.WithValue(context.Background(), "YeniDeger", "Merhaba Dünya")

    go a(ctx) // a()'yı ayrı bi goroutine içinde başlattık.

    time.Sleep(1 * time.Second) // Sonuçları görebilmek için biraz uyuyoruz.
    fmt.Println("program sonlandı")
}

>> a çalışmaya başladı
>> context içinden okunan değer: Merhaba Dünya
>> program sonlandı

Eğer aradığımız key context içinde yoksa, ctx.Value(key)'in cevabı nil olur. Bu yüzden dönen değerin nil olup olmadığını kontrol etmeliyiz.

Context - Toplu İptal

Playground

func a(ctx context.Context, idx int) {
    fmt.Println(idx, "çalışmaya başladı")

    select {
    case <-time.After(2 * time.Second):
        fmt.Println(idx, "çalışma sonlandı")
    case <-ctx.Done():
        fmt.Println(idx, "context iptal edildi")

    }
}

func main() {
    // Context'in içine bilgi gömdük, yeni bir context oluşturduk.
    baseCtx, cancel := context.WithCancel(context.Background())

    for i := 1; i <= 5; i++ {
        newCtx := context.WithValue(baseCtx, "YeniDeger", i) // baseCtx'den yeni bir context üretilir.
        go a(newCtx, i)                                      // a() yeni context ile çağırılır.
    }

    cancel() // baseCtx iptal edilir. Böylece baseCtx'den türetilen bütün context'ler iptal edilmiş olur.

    time.Sleep(5 * time.Second) // Sonuçları görebilmek için biraz uyuyoruz.
    fmt.Println("program sonlandı")
}

>> 1 çalışmaya başladı
>> 1 context iptal edildi
>> 2 çalışmaya başladı
>> 2 context iptal edildi
>> 3 çalışmaya başladı
>> 3 context iptal edildi
>> 4 çalışmaya başladı
>> 4 context iptal edildi
>> 5 çalışmaya başladı
>> 5 context iptal edildi

>> program sonlandı

Context - Http İsteği

Context'in yaygın olarak kullanıldığı senaryolardan biri. Bir kaynağa istek atarken Deadline'ı olan context oluşturup, harcanan zamanın maksimum ne kadar olabileceğini sınırlıyoruz. İstek atılan endpoint 2 saniye sonra cevap verecek şekilde ayarlandı, bizde context'imizin timeout değerine 1 saniye verdik. 1 saniye geçtikten sonra context iptal oldu ve hata olarak context deadline exceeded mesajını gördük. Eğer context'in timeout süresini 3 saniye verseydik göreceğimiz çıktı cevap alındı mesajı olacaktı. Denemesi bedava :)

func sendReq(ctx context.Context) error {
    fmt.Println("istek atılıyor")

    req, err := http.NewRequestWithContext(ctx, http.MethodGet, "https://context.free.beeceptor.com/", nil)
    if err != nil {
        return err
    }

    _, err = http.DefaultClient.Do(req)
    if err != nil {
        return err
    }

    fmt.Println("cevap alındı")
    return nil
}

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
    defer cancel()

    if err := sendReq(ctx); err != nil {
        fmt.Println("sendReq err:", err)
    }

    fmt.Println("program sonlandı")
}

>> istek atılıyor
>> sendReq err: Get "https://context.free.beeceptor.com/": context deadline exceeded
>> program sonlandı

Go - Race Condition: Detection and Prevention

Furkan Aksoy — Fri, 27 May 2022 12:35:16 +0000

A race condition occurs when two or more things (process, threat, goroutine etc.) access the same location in memory at the same time, and at least one of the accesses is a write.

Let’s analyze a quick and simple example

package main

import (
    "fmt"
    "sync"
)

const (
    stepCount    = 100000
    routineCount = 2
)

var counter int64

func main() {
    var wg sync.WaitGroup

    for i := 0; i < routineCount; i++ {
    wg.Add(1)
        go incr(&wg)
    }

    wg.Wait() // wait until all goroutines executed
    fmt.Printf("Step Count: %d\nLastValue: %d\nExpected: %d\n", stepCount, counter, stepCount*routineCount)
}

func incr(wg *sync.WaitGroup) {
    for i := 0; i < stepCount; i++ {
        counter++
    }

    wg.Done()
}

incr function is responsible to increase counter as value of the stepCount. In this example we have 2 goroutines and each one increase the counter 100000 times. Then we expect to see 200000 (routineCount x stepCount) in value of the counter variable.

Let’s look at the output of the code 🙃

Step Count: 100000
LastValue : 192801
Expected  : 200000

Ooops, we got 192801 instead of 200000 😮 . But why? What’s wrong?

Critical Section

Before go over the problem, we should know the what is the critical section. Critical section is nothing but segment of code that should not be executed by multiple processes at the same time. Only one process/routines can execute in the critical section, other ones have to wait their turns. If not, the result will be the same as the above one.

Analyze The Problem

Now we know what is critical section. Let’s go over the problem. We have 2 same routines that are increasing the counter value by applying these steps:

1. Read value of the counter
2. Add 1 to counter
3. Store increased value in counter

The critical section consists of these two steps. Routines should not execute these steps at the same time.

Let’s imagine the scenario:

Routine 1: Read value of the counter (counter = 12)
Routine 2: Read value of the counter (counter = 12)
Routine 1: Add 1 to counter (12 + 1 = 13)
Routine 1: Store increased value in counter (counter = 13)
Routine 2: Add 1 to counter (12 + 1 = 13)
Routine 2: Store increased value in counter (counter = 13)

Oops, two routines execute some steps at the same time. Although 2 routines increase the counter by 1 that means we expect the counter will be increased by 2, the counter will only increase by 1. That’s why we got the unexpected answer in the output. Routine 2 should have waited for the critical section of Routine 1 to be executed. (Race Condition 🙋)

How to Detect?

If code written in go, you’re lucky. Golang has internal race detector tool (you don’t have to install explicitly) which is written in C/C++ using ThreadSanitizer runtime library. Tool watches for unsynchronized accesses to shared variables. If it detects some race condition case, prints a warning. Please be careful when using this tool, do not run it in production. It can consume ten times the CPU and memory.

Because of its design, the race detector can detect race conditions only when they are actually triggered by running code, which means it’s important to run race-enabled binaries under realistic workloads. However, race-enabled binaries can use ten times the CPU and memory, so it is impractical to enable the race detector all the time. One way out of this dilemma is to run some tests with the race detector enabled. Load tests and integration tests are good candidates, since they tend to exercise concurrent parts of the code. Another approach using production workloads is to deploy a single race-enabled instance within a pool of running servers.

How to Use Race-Detector Tool?

No need to install anything. It’s fully integrated with the Go tool chain. Just add a -race flag while compiling/running your application.

$ go test -race mypkg    // test the package
$ go run -race mysrc.go  // compile and run the program
$ go build -race mycmd   // build the command
$ go install -race mypkg // install the package

Let’s run it for our racy code.

$ go run -race main.go

==================
WARNING: DATA RACE
Read at 0x000001279320 by goroutine 8:
  main.incr()
      main.go:29 +0x47

Previous write at 0x000001279320 by goroutine 7:
  main.incr()
      main.go:29 +0x64

Goroutine 8 (running) created at:
  main.main()
      main.go:20 +0xc4

Goroutine 7 (running) created at:
  main.main()
      main.go:20 +0xc4
==================
Step Count: 100000
LastValue : 192801
Expected : 200000

Found 1 data race(s)
exit status 66

Results shows that an unsynchronized events of the variable counter from different routines. We’ll go over the solution in next section.

Another points to prevent and detect the race conditions are that

qualified code reviews
designing and modeling applications that use as little shared resources as possible
increasing know-how about such situations
unit-tests for concurrent things

How to Handle?

Until know, we understood the problem and detect the bug. Let’s fix it!

Using Mutex

Mutex (mutual exclusion) is a lock/unlock mechanism for critical sections. If it’s locked, the critical section is reserved for one goroutine, other ones have to wait until unlocking. In our code, we should lock the code that increases the counter. Other goroutines should not be able to increase the counter if one goroutine is already working on it.

package main

import (
    "fmt"
    "sync"
)

const (
    stepCount    = 100000
    routineCount = 2
)

var counter int64

func main() {
    var wg sync.WaitGroup
    var mx sync.Mutex // initialize mutex

    for i := 0; i < routineCount; i++ {
    wg.Add(1)
        go incr(&wg, &mx) // pass mutex to each routine
    }

    wg.Wait() // wait until all goroutines executed
    fmt.Printf("Step Count: %d\nLastValue: %d\nExpected: %d\n", stepCount, counter, stepCount*routineCount)
}

func incr(wg *sync.WaitGroup, mx *sync.Mutex) {
    for i := 0; i < stepCount; i++ {
        mx.Lock() // lock critical section for this routine
        counter++  // critical section
        mx.Unlock() // unlock critical section then other routines can use it.
    }

    wg.Done()
}

Using Channels

According to the go document;

Channels are the pipes that connect concurrent goroutines. You can send values into channels from one goroutine and receive those values into another goroutine.

It’s a simple pipe actually. In this scenario we can use buffered channels with capacity 1 to synchronize our goroutines. That means channel accept only one data in it, does not accept the new data until current one read.

Long story short, we should pass the channel to fired routines, and each routine should send a some value to channel to block other routines. When it’s done, routine should clean out the channel to allow other routines. It’s like a lock/unlock mechanism provided by mutex.

package main

import (
    "fmt"
    "sync"
)

const (
    stepCount    = 100000
    routineCount = 2
)

var counter int64

func main() {
    var wg sync.WaitGroup
    ch := make(chan struct{}, 1) // define buffered channel 

    for i := 0; i < routineCount; i++ {
        wg.Add(1)
        go incr(&wg, ch)
    }

    wg.Wait() // wait until all goroutines executed
    fmt.Printf("Step Count: %d\nLastValue: %d\nExpected: %d\n", stepCount, counter, stepCount*routineCount)
}

func incr(wg *sync.WaitGroup, ch chan struct{}) {
    ch <- struct{}{} // send empty struct into channel to block other routines.
    for i := 0; i < stepCount; i++ {
        counter++
    }
    <- ch // clear out the channel

    wg.Done()
}

Using Atomic Package

Atomic function does not need any lock, they are implemented at hardware level. If performance really important for you, atomic package can be used to create lock-free application. But, you or your team should know how atomic functions work in-behind. For example atomic variables should be controlled by only atomic functions. Don’t read or write like a classic variable.

package main

import (
    "fmt"
    "sync"
    "sync/atomic"
)

const (
    stepCount    = 100000
    routineCount = 2
)

var counter int64

func main() {
    var wg sync.WaitGroup

    for i := 0; i < routineCount; i++ {
        wg.Add(1)
        go incr(&wg)
    }

    wg.Wait() // wait until all goroutines executed
    fmt.Printf("Step Count: %d\nLastValue: %d\nExpected: %d\n", stepCount, counter, stepCount*routineCount)
}

func incr(wg *sync.WaitGroup) {
    for i := 0; i < stepCount; i++ {
        atomic.AddInt64(&counter, 1) // use atomic function to increase counter
    }

    wg.Done()
}

DEV Community: Furkan Aksoy

Chain of Responsibility Pattern in Go

Example

What is next field in this example?

Conclusion

Functional Options Pattern in Go

Introduction

What is the Functional Options Pattern?

How does it work?

What is variadic function?

Example

[TR] Golang - Context Nedir?

Golang - Context Nedir?

Context 101

Örnek: İptal Sinyali

Örnek: İstek Tabanlı Veriler

Context'e Yakından Bakış

Hazır Context Tipleri

Background

TODO

Context Oluşturma

Cancel Fonksiyonu

Kod Örnekleri

Context - İptal

Context - Zaman Aşımı

Context - Bilgi Gömmek

Context - Toplu İptal

Context - Http İsteği

Go - Race Condition: Detection and Prevention

Critical Section

Analyze The Problem

How to Detect?

How to Use Race-Detector Tool?

How to Handle?

Using Mutex

Using Channels

Using Atomic Package

`Cancel` Fonksiyonu