6 ms·

I'm not sure what you are implying here. Should we give up on creating a language that can have millions of threads because we might break selinux? Should we gi

I'm not sure what you are implying here. Should we give up on creating a language that can have millions of threads because we might break selinux? Should we give up on programs with millions of threads because someone in the 1970's never foresaw that use case?

pcwalton 10y ago
> Should we give up on programs with millions of threads because someone in the 1970's never foresaw that use case? It's not that simple. I think there's a reasonable first-principles argument to be made that scheduling belongs in the kernel, which has a global view of the system and is better equipped to make those decisions.
- ben0x539 10y ago
  Some Go users can probably make the argument that their one Go application is the single process using appreciable amounts of CPU time on their systems.
  - ben0x539 10y ago
    Well, or some Erlang users, I guess, fine
- felixgallo 10y ago
  The kernel is necessarily so general purpose that it's hardly equipped at all to make correct, performant scheduling decisions at the app level.
- toast0 10y ago
  I use erlang, not go, but it does similar things. On most of our production machines, the only OS process dong real work is the erlang VM, other processes are just things like crond, ntpd, sshd, syslogd; so all the kernel scheduler has to do is run the erlang OS threads (and they're pined to individual CPUs). Maybe the kernel scheduler would do a better job, but is it realistic to run 1M OS threads? It feels like the overhead per green thread is much lower, and the potential for being interrupted in a critical section is also much lower: An OS thread may be paused while holding a (vm internal) lock, but the vm scheduler would not preempt a green thread in the middle of doing something that requires a lock (ex: Delivering a message to another green thread)
  - stymaar 10y ago
    > but is it realistic to run 1M OS threads? It feels like the overhead per green thread is much lower What kind of overhead do OS thread have that green thread doesn't ? I'm aware of the stack size, but is there something else ? If the stack size is the only culprit here, what prevents the admin from manually setting a small stack size that will be enough for most operation (in practice, I don't know how useful the ability to grow dynamically the stack size in languages with green threads). > An OS thread may be paused while holding a (vm internal) lock, but the vm scheduler would not preempt a green thread in the middle of doing something that requires a lock (ex: Delivering a message to another green thread) That's an interesting point.
    - toast0 10y ago
      > What kind of overhead do OS thread have that green thread doesn't ? I'm aware of the stack size, but is there something else ? Real context switches (with cache invalidation) to switch between, system call (with context switch to kernel) to create/dispose, probably kernel bits that will explode with huge thread lists: I wouldn't be surprised if listing all threads with ps or top also locks the thread lists: not a big deal if you have a reasonable number of threads, but could block thread creation in a 1M thread case.
      - pcwalton 10y ago
        Context switches are really fast on modern x86.
        Jweb_Guru 10y ago
        Plus there are specialized hardware instructions for them, and the expensive parts (saving weird registers etc.) are fast-pathed in Linux if they're not being used.
        toast0 10y ago
        > Context switches are really fast on modern x86. Not context switching is even faster. How fast is really fast, how modern is modern? some results from 2010 [1] show at least 1000 nanoseconds per context switch (even with optimizations for the kernel switching between threads of the same process). That's not that slow, but it is a lot of time you could be doing something else. [1] http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma... [1] http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma...
zzzcpan 10y ago
> Should we give up on programs with millions of threads We gave up on this already, as multithreading is not even a little bit decent model for concurrency.
- Jweb_Guru 10y ago
  Okay. What is a decent model for concurrency that incorporates shared mutable memory (which, like it or not, is [1] a thing that exists on real machines and is impossible to avoid, and [2] is very much alive and well in Go) and isn't basically threads redux? I seriously have no clue what people mean when they say things like this.

pcwalton 10y ago

> Should we give up on programs with millions of threads because someone in the 1970's never foresaw that use case? It's not that simple. I think there's a reasonable first-principles argument to be made that scheduling belongs in the kernel, which has a global view of the system and is better equipped to make those decisions.

ben0x539 10y ago
Some Go users can probably make the argument that their one Go application is the single process using appreciable amounts of CPU time on their systems.
- ben0x539 10y ago
  Well, or some Erlang users, I guess, fine
felixgallo 10y ago
The kernel is necessarily so general purpose that it's hardly equipped at all to make correct, performant scheduling decisions at the app level.
toast0 10y ago
I use erlang, not go, but it does similar things. On most of our production machines, the only OS process dong real work is the erlang VM, other processes are just things like crond, ntpd, sshd, syslogd; so all the kernel scheduler has to do is run the erlang OS threads (and they're pined to individual CPUs). Maybe the kernel scheduler would do a better job, but is it realistic to run 1M OS threads? It feels like the overhead per green thread is much lower, and the potential for being interrupted in a critical section is also much lower: An OS thread may be paused while holding a (vm internal) lock, but the vm scheduler would not preempt a green thread in the middle of doing something that requires a lock (ex: Delivering a message to another green thread)
- stymaar 10y ago
  > but is it realistic to run 1M OS threads? It feels like the overhead per green thread is much lower What kind of overhead do OS thread have that green thread doesn't ? I'm aware of the stack size, but is there something else ? If the stack size is the only culprit here, what prevents the admin from manually setting a small stack size that will be enough for most operation (in practice, I don't know how useful the ability to grow dynamically the stack size in languages with green threads). > An OS thread may be paused while holding a (vm internal) lock, but the vm scheduler would not preempt a green thread in the middle of doing something that requires a lock (ex: Delivering a message to another green thread) That's an interesting point.
  - toast0 10y ago
    > What kind of overhead do OS thread have that green thread doesn't ? I'm aware of the stack size, but is there something else ? Real context switches (with cache invalidation) to switch between, system call (with context switch to kernel) to create/dispose, probably kernel bits that will explode with huge thread lists: I wouldn't be surprised if listing all threads with ps or top also locks the thread lists: not a big deal if you have a reasonable number of threads, but could block thread creation in a 1M thread case.
    - pcwalton 10y ago
      Context switches are really fast on modern x86.
      - Jweb_Guru 10y ago
        Plus there are specialized hardware instructions for them, and the expensive parts (saving weird registers etc.) are fast-pathed in Linux if they're not being used.
      - toast0 10y ago
        > Context switches are really fast on modern x86. Not context switching is even faster. How fast is really fast, how modern is modern? some results from 2010 [1] show at least 1000 nanoseconds per context switch (even with optimizations for the kernel switching between threads of the same process). That's not that slow, but it is a lot of time you could be doing something else. [1] http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma... [1] http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma...

zzzcpan 10y ago

> Should we give up on programs with millions of threads We gave up on this already, as multithreading is not even a little bit decent model for concurrency.

Jweb_Guru 10y ago
Okay. What is a decent model for concurrency that incorporates shared mutable memory (which, like it or not, is [1] a thing that exists on real machines and is impossible to avoid, and [2] is very much alive and well in Go) and isn't basically threads redux? I seriously have no clue what people mean when they say things like this.