4 ms·

Go schedules its own 'threads' (goroutines) to run on one or many (OS) threads. In this case, threads refer to not-a-process units of execution in an operating

Go schedules its own 'threads' (goroutines) to run on one or many (OS) threads. In this case, threads refer to not-a-process units of execution in an operating system. For whatever its worth, Wikipedia defines threads as: the smallest sequence of programmed instructions that can be managed independently by an operating system scheduler. I think that's also the commonly accepted definition: that threads are related to the OS scheduler.

tptacek 14y ago
The notion that goroutines aren't threads seems to exist primarly because Golang also makes use of OS-native threads in order to schedule goroutines, and so needs to draw a distinction in order to explain how the runtime works. But that's just a detail. In reality, goroutines are threads; they're just userland, non-preemptive threads. Similar constructions have been available, even to C programmers, for well over a decade (and probably much longer).
- furyofantares 14y ago
  > Similar constructions have been available, even to C programmers, for well over a decade (and probably much longer). Of course they aren't called threads there, either (probably for the same reason as they aren't called threads in Go)
  - tptacek 14y ago
    Sure they are. For instance, Gnu Pth. Programming language support for threading predates direct operating system support (at least in mainstream operating systems) by a lot of years, from what I can tell.
    - furyofantares 14y ago
      The ones I've used have just been called coroutines, though I suppose I haven't used any that function as drop-in replacements for threads like Pth
georgemcbay 14y ago
It is really common for Go programmers (I've even seen members of the Go core team do it) to say 'thread' when they mean goroutine. It is important to recognize there is a difference, but calling someone out for saying 'thread' when they mean 'goroutine' is pedantic bullshit on the order of calling someone out for calling a class method in an OO language a function.
- AYBABTME 14y ago
  Oh I'm not (I didn't meant to?) calling parent out, I was just trying an explanation.
  - abecedarius 14y ago
    Thanks for explaining -- I really couldn't tell what distinction they meant.
  - georgemcbay 14y ago
    Sorry if where I replied made this confusing, I wasn't really talking about you nor even did I mean it as a personal thing against Jabbles who did the actual "calling out" of mixing threads and goroutines. As I mentioned, knowing the difference is actually a good thing so your post is really helpful. My point is just that the two concepts are so intertwined and overlapping that I think it is silly for someone to correct someone's terminology on this (as Jabbles did, though I admit I share some of his(?) other concerns with the OP), particularly in cases where it is clear the person is pretty familiar with goroutines and how they operate.
dllthomas 14y ago
http://en.wikipedia.org/wiki/Green_threads http://en.wikipedia.org/wiki/Green_threads
smegel 14y ago
Its not a commonly accepted "definition" - threads are a general concept that encompass several different forms of concurrency. It may be commonly assumed that the term "thread", in absence of any other qualifier, refers to OS-level threads, however even that is context dependent. The Wikipedia page introduction is poorly written. However the more salient point here is the OP was either being lazy by saying "goroutines are not threads", or actually doesn't understand the concept of lightweight threads. Along the lines of Rob Pike's own explanation on the matter, he maybe should have said "goroutines provide concurrency but not parallelization".
- mseepgood 14y ago
  > "goroutines provide concurrency but not parallelization" If they are multiplexed on several threads, then they also provide parallelization.
shadowfox 14y ago
> that threads are related to the OS scheduler It is actually common for people to talk about green threads (http://en.wikipedia.org/wiki/Green_threads http://en.wikipedia.org/wiki/Green_threads) in the same vain as OS threads.

tptacek 14y ago

The notion that goroutines aren't threads seems to exist primarly because Golang also makes use of OS-native threads in order to schedule goroutines, and so needs to draw a distinction in order to explain how the runtime works. But that's just a detail. In reality, goroutines are threads; they're just userland, non-preemptive threads. Similar constructions have been available, even to C programmers, for well over a decade (and probably much longer).

furyofantares 14y ago
> Similar constructions have been available, even to C programmers, for well over a decade (and probably much longer). Of course they aren't called threads there, either (probably for the same reason as they aren't called threads in Go)
- tptacek 14y ago
  Sure they are. For instance, Gnu Pth. Programming language support for threading predates direct operating system support (at least in mainstream operating systems) by a lot of years, from what I can tell.
  - furyofantares 14y ago
    The ones I've used have just been called coroutines, though I suppose I haven't used any that function as drop-in replacements for threads like Pth

georgemcbay 14y ago

It is really common for Go programmers (I've even seen members of the Go core team do it) to say 'thread' when they mean goroutine. It is important to recognize there is a difference, but calling someone out for saying 'thread' when they mean 'goroutine' is pedantic bullshit on the order of calling someone out for calling a class method in an OO language a function.

AYBABTME 14y ago
Oh I'm not (I didn't meant to?) calling parent out, I was just trying an explanation.
- abecedarius 14y ago
  Thanks for explaining -- I really couldn't tell what distinction they meant.
- georgemcbay 14y ago
  Sorry if where I replied made this confusing, I wasn't really talking about you nor even did I mean it as a personal thing against Jabbles who did the actual "calling out" of mixing threads and goroutines. As I mentioned, knowing the difference is actually a good thing so your post is really helpful. My point is just that the two concepts are so intertwined and overlapping that I think it is silly for someone to correct someone's terminology on this (as Jabbles did, though I admit I share some of his(?) other concerns with the OP), particularly in cases where it is clear the person is pretty familiar with goroutines and how they operate.

dllthomas 14y ago

http://en.wikipedia.org/wiki/Green_threads http://en.wikipedia.org/wiki/Green_threads

smegel 14y ago

Its not a commonly accepted "definition" - threads are a general concept that encompass several different forms of concurrency. It may be commonly assumed that the term "thread", in absence of any other qualifier, refers to OS-level threads, however even that is context dependent. The Wikipedia page introduction is poorly written. However the more salient point here is the OP was either being lazy by saying "goroutines are not threads", or actually doesn't understand the concept of lightweight threads. Along the lines of Rob Pike's own explanation on the matter, he maybe should have said "goroutines provide concurrency but not parallelization".

mseepgood 14y ago
> "goroutines provide concurrency but not parallelization" If they are multiplexed on several threads, then they also provide parallelization.

shadowfox 14y ago

> that threads are related to the OS scheduler It is actually common for people to talk about green threads (http://en.wikipedia.org/wiki/Green_threads http://en.wikipedia.org/wiki/Green_threads) in the same vain as OS threads.