5 ms·

> even so-called "modern" operating systems > like macOS 10.12 and Windows 8.1 simply > melted or failed entirely when creating > any non-trivial numbe

> even so-called "modern" operating systems > like macOS 10.12 and Windows 8.1 simply > melted or failed entirely when creating > any non-trivial number of threads. (To > me, creating 100 threads should be a no-brainer This is nonsense. NT kernel happily creates thousands of threads. Just made a little test app to try. No issues at all.

laythea 9y ago
Can confirm. 155 processes, 1770 threads, and 60999 handles. According to Task Manager.
api 9y ago
I hear the claim pretty often that threads won't scale and that even modern OSes can't handle many threads. It makes me wonder if people are doing something different, since I've found that threads are fine.
jesseb 9y ago
I raised an eyebrow at that as well. My workstation running Windows 10 is currently chugging along with 236 Processes, 3564 Threads and 154915 Handles, which is pretty typical of this system.
- AstralStorm 9y ago
  Of those, how many are actually active? (equivalent to R state in procps)
  - dmitrygr 9y ago
    if num_active_processes is much larger than number of cores, then your software architecture is wrong and you're just stress testing your OS's lock primitives and CPU's TLB logic. Lots of threads/processed blocked on stuff is ok. Lots of them all wanting to run and be CPU bound is bad design
farazbabar 9y ago
Modern operating systems are very efficient at scheduling threads with negligible workloads compared to threads that are performing under load. I suspect that a lot of test code for toy examples and default workload for thousands of threads you see on an operating system has running at any given time is probably not cpu intensive enough to matter. Compared to this, a library designed to perform actual work using hundreds of threads on a modern os with let's say 8 cpu cores - simply won't work due to the constant context switching overhead. Consider the library called LMAX disruptor as an example of this behavior where developers need to configure threads to be equal to number of available cpus if they wish to do busy_wait processing for inbound messages on the ring buffer. Chronicle Q actually uses JNI to pin message processing threads to individual CPU cores to make sure operating system scheduling does not end up flushing L1/L2 caches and that message processing for a given queue continues to occur on the same thread/cpu combo. So it depends on your use-case and application.
- otabdeveloper1 9y ago
  There's no such thing as a "context switching overhead". You don't understand how operating systems work. The OS context switches to the next available thread at fixed time intervals. It doesn't matter if you have 5 threads or 5000, the number of context switches is the same. The only difficulty is deciding which thread is the "next available" one. This is the job of the process scheduler. Normally, the process scheduler is a complex heuristic affair that tries to pick a more deserving thread based on some black magic rules of thumb. Under certain loads this black magic can backfire, picking some threads more frequently while letting others starve. If you know your workload, you can use a scheduler without magic heuristics. These kinds of schedulers are called "real time". Try them, you'll be surprised.
  - viraptor 9y ago
    > There's no such thing as a "context switching overhead". So what do you call the time spent changing the system internal information about the currently executing thread, switching page tables via cr3 and the invalidation it causes, and the time wasted because of cache misses (although a lot of it can be reclaimed with CPU pinning). Because that's what people normally call "context/thread switching overhead" > The OS context switches to the next available thread at fixed time intervals. It doesn't matter if you have 5 threads or 5000, the number of context switches is the same. Not just at fixed intervals. If your threads are doing io work, more threads will switch more often because they will issue io requests forcing waits/yields. If they do pure-cpu work, that doesn't apply, but we're talking about networking mostly in these comments.
theincredulousk 9y ago
Of course no offense, but the author does seem to be somewhere shortly after the first peak on the Dunning-Kruger curve. Even truly embedded systems with an OS like QNX don't "melt" with 100 threads. Obviously he "doesn't know what he doesn't know" in expertise terms, and blamed a mistake on the operating systems. That combined with the other extremely dubious reasoning - e.g. (see my other very long comment) how replacing state machines with callback functions is a good idea (tm). There is also the comment RE: "how bad Windows APIs are" and how IO-completion ports are '_actually_ pretty nice'. This is the kind of comment someone makes if their worried the "real" coders won't take them seriously if they use anything but Arch Linux. Makes you think he is reasoning about things that he just isn't an expert in yet (embedded systems, operating system APIs, long-term framework design). Nothing wrong with that though - everyone has to build up experience somehow - but maybe a bit early to be on the front page of HN.
- jclulow 9y ago
  I think Garrett has been doing all of the things you're talking about for quite a long time. I'm not saying this experience makes him correct per se, but come on -- this is just poorly constructed character assassination on your part.
  - theincredulousk 9y ago
    In retrospect this is probably true. Should have left it at the comment about QNX - the rest is honestly irrelevant. Apologies to Garret for assassinating his character based on a single blog post.

laythea 9y ago

Can confirm. 155 processes, 1770 threads, and 60999 handles. According to Task Manager.

api 9y ago

I hear the claim pretty often that threads won't scale and that even modern OSes can't handle many threads. It makes me wonder if people are doing something different, since I've found that threads are fine.

jesseb 9y ago

I raised an eyebrow at that as well. My workstation running Windows 10 is currently chugging along with 236 Processes, 3564 Threads and 154915 Handles, which is pretty typical of this system.

AstralStorm 9y ago
Of those, how many are actually active? (equivalent to R state in procps)
- dmitrygr 9y ago
  if num_active_processes is much larger than number of cores, then your software architecture is wrong and you're just stress testing your OS's lock primitives and CPU's TLB logic. Lots of threads/processed blocked on stuff is ok. Lots of them all wanting to run and be CPU bound is bad design

farazbabar 9y ago

Modern operating systems are very efficient at scheduling threads with negligible workloads compared to threads that are performing under load. I suspect that a lot of test code for toy examples and default workload for thousands of threads you see on an operating system has running at any given time is probably not cpu intensive enough to matter. Compared to this, a library designed to perform actual work using hundreds of threads on a modern os with let's say 8 cpu cores - simply won't work due to the constant context switching overhead. Consider the library called LMAX disruptor as an example of this behavior where developers need to configure threads to be equal to number of available cpus if they wish to do busy_wait processing for inbound messages on the ring buffer. Chronicle Q actually uses JNI to pin message processing threads to individual CPU cores to make sure operating system scheduling does not end up flushing L1/L2 caches and that message processing for a given queue continues to occur on the same thread/cpu combo. So it depends on your use-case and application.

otabdeveloper1 9y ago
There's no such thing as a "context switching overhead". You don't understand how operating systems work. The OS context switches to the next available thread at fixed time intervals. It doesn't matter if you have 5 threads or 5000, the number of context switches is the same. The only difficulty is deciding which thread is the "next available" one. This is the job of the process scheduler. Normally, the process scheduler is a complex heuristic affair that tries to pick a more deserving thread based on some black magic rules of thumb. Under certain loads this black magic can backfire, picking some threads more frequently while letting others starve. If you know your workload, you can use a scheduler without magic heuristics. These kinds of schedulers are called "real time". Try them, you'll be surprised.
- viraptor 9y ago
  > There's no such thing as a "context switching overhead". So what do you call the time spent changing the system internal information about the currently executing thread, switching page tables via cr3 and the invalidation it causes, and the time wasted because of cache misses (although a lot of it can be reclaimed with CPU pinning). Because that's what people normally call "context/thread switching overhead" > The OS context switches to the next available thread at fixed time intervals. It doesn't matter if you have 5 threads or 5000, the number of context switches is the same. Not just at fixed intervals. If your threads are doing io work, more threads will switch more often because they will issue io requests forcing waits/yields. If they do pure-cpu work, that doesn't apply, but we're talking about networking mostly in these comments.

theincredulousk 9y ago

Of course no offense, but the author does seem to be somewhere shortly after the first peak on the Dunning-Kruger curve. Even truly embedded systems with an OS like QNX don't "melt" with 100 threads. Obviously he "doesn't know what he doesn't know" in expertise terms, and blamed a mistake on the operating systems. That combined with the other extremely dubious reasoning - e.g. (see my other very long comment) how replacing state machines with callback functions is a good idea (tm). There is also the comment RE: "how bad Windows APIs are" and how IO-completion ports are '_actually_ pretty nice'. This is the kind of comment someone makes if their worried the "real" coders won't take them seriously if they use anything but Arch Linux. Makes you think he is reasoning about things that he just isn't an expert in yet (embedded systems, operating system APIs, long-term framework design). Nothing wrong with that though - everyone has to build up experience somehow - but maybe a bit early to be on the front page of HN.

jclulow 9y ago
I think Garrett has been doing all of the things you're talking about for quite a long time. I'm not saying this experience makes him correct per se, but come on -- this is just poorly constructed character assassination on your part.
- theincredulousk 9y ago
  In retrospect this is probably true. Should have left it at the comment about QNX - the rest is honestly irrelevant. Apologies to Garret for assassinating his character based on a single blog post.