Concurrency in Go si cum am evitat data races

[HKS 27D]

Concurrency in Go

In urma cu ceva timp, lucram cu date in moduri total nepotrivite. Era posibil sa avem data races in orice moment. Ce inseamna asta, mai exact? Conform go.dev: A data race occurs when two goroutines access the same variable concurrently and at least one of the accesses is a write [...]. Asta poate conduce la comportament neasteptat sau crash-uri. Ce concurrency sa faci, cand ai data races in software-ul la care lucrezi?

 

Cum am implementat concurrency in Go

Ce am facut sa evitam problema de data races? Atomicity si mutual exclusion. Pe langa asta, am implementat sharding pentru tipurile de date custom acolo unde am considerat ca este o caracteristica de tip must-have. In acest mod evitam mutex contention (performance bottleneck, poor scalability). De dragul unor valori exceptionale pentru partea de raw performance, am mers atat de departe incat am utilizat o implementare custom pentru date concurente in loc sa folosim libraria sync.Map din Go. Comparatia rezultatelor din benchmark-uri spune tot: am obtinut o performanta remarcabila cu 0 alocari de memorie aditionale, in timp ce libraria sync.Map are o performanta mai slaba si face alocari de memorie aditionale. Implementarea custom-made a fost grozava pentru use case-ul nostru. A depasit asteptarile initiale in timp ce am obtinut ceea ce am cautat.

 

Rezultate aplicatii Go

1. No data race => no crashes or unpredictable behavior
2. Lower RAM consumption compared to standard library
3. High concurrency & scalability

 

Concluzie data races

Concluzia e simpla: luati in calcul conceptul de data races atunci cand aveti de-a face cu medii unde partea de concurrency conteaza.

Aceste lucruri sunt aplicabile nu doar in Go, ci in orice alt limbaj de programare pe care il adoptati pentru scrierea de software sau munca din backend.