What is State of concurrency in go on Arm architecture


(Hridyansh Thakur) #1

i have used go-lang on my arm devices but there is a little bit insecurity about support for concurrency on architectures like arm v7/v6/v8 (they hold so less market that supporting a complex features like concurrency on them does not look productive from viewpoint of devs), is there anyone who has enough experience of using go on these architectures to confidently say that concurrency works fine of these architectures (like spawning number of OS threads distributed across physical cores [i am aware of the fact that there is no assurance of them working on different cores ])


(George Calianu) #2

I used concurrency on ARM (Raspberry Pi3) and i had no problems. Anyway, the concurrency in Go is not multithreading but an internal management of goroutines so, i guess you should have no worries about it.


(Ignacio Gómez) #3

Same here using RPi 3, and I also built a RPi Zero (one core only) based gateway with some goroutines and had no issues.


(Jay Ts) #4

As George said, concurrency is implemented by the Go runtime, and is independent of the specific hardware Go is running on. If Go works on a specific architecture and operating system, then the worst thing that will happen is that all of the Go routines will run in the same OS process and thread. That would be if the operating system were single-tasking only, which is rare nowadays.

Go is available for Windows, macOS, Linux, and some Unix operating systems. All of them support multiprocessing and multiple threads. When Go runs on them (with an exception or two like WebAssembly), Go manages goroutines (concurrency) in its own runtime system, along with distributing the goroutines across multiple CPU cores and CPU threads using the operating system’s support for multithreading.