Does Windows have a limit of 2000 threads per process?

re: Does Windows have a limit of 2000 threads per process?

Tim Smith — Fri, 29 Jul 2005 17:15:16 GMT

Maybe I am just getting grumpy in my old age but...

I've done plenty of non-scalable threading system. I would even swear Larry O. used some of my code in an article about poor threading models using events. But I understood it the ramifications of what I was doing. I knew it wouldn't work well in a high stress environment.

Are people programming these days without a basic understanding of how computers work? A simple philosophy of "Nothing is free" would raise a red flag on the 2000 thread issue. Even before I got to sentence two in this article I was asking "But why?"

*sigh* *rant off*

The really sad thing is that it all the programmers who know they still have a lot to learn are the guys who are reading these blogs. It is the people who don't know that they don't have a clue who need to be here.

Ugh, I shouldn't post before my morning coke.

re: Does Windows have a limit of 2000 threads per process?

Travis Owens — Fri, 29 Jul 2005 17:19:37 GMT

Of course we could raise the question, should any application be generating THAT many threads that this should be an issue in the first place.

Or maybe I'm re-preaching "640k is enough for anybody" concepts.

re: Does Windows have a limit of 2000 threads per process?

Joe Chung — Fri, 29 Jul 2005 17:55:52 GMT

While it doesn't make sense to have 2000+ threads on a single CPU yet, it might make sense in the (not so far) future when a machine may have several processors, each of which might be multi-core (2 or more processors per chip).

re: Does Windows have a limit of 2000 threads per process?

Tim Ritchey — Fri, 29 Jul 2005 18:17:00 GMT

Ahh, I/O Completion ports. Everyone seems to be on an IOCP kick these days. I was all excited about them myself until I learned that you cannot support older versions of Windows. At that point, the consensus seemed to be that OVERLAPPED I/O was the way to go for scalable networking sans threads. God help you if you are looking for a good example of how to create a robust overlapped networking application. At least more than just a simple echo client and echo server. I spent more time than I would like to admit getting everything to work. I don't suppose anyone knows of a good real-world example of OVERLAPPED networking?

re: Does Windows have a limit of 2000 threads per process?

kbiel — Fri, 29 Jul 2005 18:23:22 GMT

I think Raymond has it right, the people asking this question are probably creating a thread per object. They probably don't have an expectation to run all 2000+ threads simultaneously, they just don't understand thread pooling.

re: Does Windows have a limit of 2000 threads per process?

mschaef — Fri, 29 Jul 2005 18:34:54 GMT

'The "one thread per client" model is well-known not to scale beyond a dozen clients or so.'

Perhaps that should read 'one win32 operating system thread per client'. From what I understand, never having used it myself, Erlang does a pretty good job of making application level threads cheap to create and dispatch:

http://wagerlabs.com/tech/2005/05/27000-games.html

"I have a PowerBook G4 1.25Ghz with 512Mb of memory. Running 27K games consumes about 600Mb of memory and takes around 15 minutes per 10K games due to heavy swapping. ... Assuming an average of 5 players per game that's 135,000 players and 405,000 simultaneous processes. "

As you've pointed out before (http://blogs.msdn.com/oldnewthing/archive/2005/02/11/371042.aspx) sometimes it makes sense to think past OS-native services.

re: Does Windows have a limit of 2000 threads per process?

Ray Trent — Fri, 29 Jul 2005 18:49:37 GMT

32-bit Windows... how... 20th century.

So I guess this isn't likely to be a limit for very much longer, eh?

Of course, people will complain about having a mere 8 trillion threads, no doubt...

re: Does Windows have a limit of 2000 threads per process?

oldnewthing — Fri, 29 Jul 2005 18:52:58 GMT

Of course if you disallow native code you can get away with more tricks. A continuation does a lot less memory than a thread but its use is limited to managed environments. Great work if you can get it.

re: Does Windows have a limit of 2000 threads per process?

mgrier — Fri, 29 Jul 2005 19:18:02 GMT

The core problem here is the sequential programming model combined with the native compilers' reliance on the machine stack.

As Raymond points out, continuations can effectively give you a ton of "threads". You don't need managed code; there have been plenty of native-code-generating continuation-passing languages over the years. Continuation-passing doesn't even solve everything because you need synchronization primitives which are associated with these continuations/contexts instead of operating system units of execution. (For example, I have no idea how well critical sections and fibers interact on NT...)

You do have to wonder then what a "thread" means. If it means whatever you want it to mean in a context, we're compating apples and oranges. In Raymond's context, he's talking about threads as an OS scheduling concept, not a programming language level concept.

re: Does Windows have a limit of 2000 threads per process?

Skilled and Aware of it — Fri, 29 Jul 2005 20:26:40 GMT

re: Tim Smith:
http://www.phule.net/mirrors/unskilled-and-unaware.html

re: Does Windows have a limit of 2000 threads per process?

nikita — Fri, 29 Jul 2005 21:30:20 GMT

It's true that thread-per-connection architecture has scalability problems, but its alternative has its drawbacks too. So many of them actually, that after my first serious encounter with non-blocking-state-machine type of server (SquidNG, circa 2000), I ended up compiling a list of problems I had with that type of architecture: http://nikita.w3.to/thread-per-connection.html

Since then I had to write a lot of similar code both in user and kernel space, but my opinion is still the same: "Async servers? Not in C.".

re: Does Windows have a limit of 2000 threads per process?

Jonathan — Fri, 29 Jul 2005 22:23:28 GMT

Presumably this limit is higher in 64-bit processes?

re: Does Windows have a limit of 2000 threads per process?

Ulric — Sat, 30 Jul 2005 00:21:08 GMT

STACK_SIZE_PARAM_IS_A_RESERVATION is new in XP, for previous versions of Windows we're entirely stuck because you can only increase the reserved stack side for each thread from the default, not decrease it.

This means that since the main UI thread generally has a pretty large stack (several megs, for example, in a significant C++ application), any worker or helper thread end up having as large a reserved stack size. This results in applications taking up much more memory than they anticipate for every additionnal thread, without knowing it. Something I learned the hard way, let's just say!

re: Does Windows have a limit of 2000 threads per process?

Shailesh — Sat, 30 Jul 2005 00:54:14 GMT

From MSDN topic "Thread Stack Size" : "A stack is freed when its thread exits. It is not freed if the thread is terminated by another thread."

Why exactly is the stack not freed if terminated by another thread?

re: Does Windows have a limit of 2000 threads per process?

an0nym0us — Sat, 30 Jul 2005 03:25:39 GMT

I/O Completion ports work until you get blocked by a library or system API that is inherently sequential and does support overlapped operations (Winsock name resolution, and authentication APIs, for example). These can take few seconds and then you end up with a thread-per-client or a denial of service.

re: Does Windows have a limit of 2000 threads per process?

LarryOsterman — Sat, 30 Jul 2005 04:42:28 GMT

Shailesh, because terminating a thread means simply unhooking it from the scheduler (which causes it to stop executing since it will never be scheduled again).

The NT scheduler doesn't know about thinks like "stacks", a "stack" is a memory management thingy.

re: Does Windows have a limit of 2000 threads per process?

dinov — Sat, 30 Jul 2005 08:16:09 GMT

mgrier:

On fibers & critical sections: they work like water & oil. Critical sections are per-thread and don't see fibers at all. If Fiber a is running on thread 1 and takes a crst and then is switched out & back in on thread 2 and attempts to re-acquire the critical section it blocks. If fiber b was previously running on thread 3 and is then switched to thread 1 and attempts to acquire the same critical section it succeeds.

This and all other thread based synchronization (in other words, all synchronization) was one of the big gotchas with the CLR & fiber mode support. It's easy to eliminate this in your own code, but harder to eliminate from other code in your process. One fun issue is the loader lock - which is just another critical section to watch out for (and on win64 it gets more fun w/ exception handling!). Not to mention all the other thread-locale state that you need to watch out for that may bite you when using fibers.

Ahh fibers... this is not the answer you're looking for.

re: Does Windows have a limit of 2000 threads per process?

Nathan Moore — Sat, 30 Jul 2005 08:23:20 GMT

Re: mschaef

That poker tech thing is talking about processes not threads. You are comparing apples and oranges.

re: Does Windows have a limit of 2000 threads per process?

mschaef — Sun, 31 Jul 2005 00:40:11 GMT

Re: Nathan Moore

I believe the term process, in this context, comes from Tony Hoare's "Communicating Sequential Processes", a book that contains a lot of the theoretical basis of Erlang.

From http://www.erlang.org/faq/t1.html,

"Concurrency and message passing are a fundamental to the language. Applications written in Erlang are often composed of hundreds or thousands of lightweight processes.Context switching between Erlang processes is typically one or two orders of magnitude cheaper than switching between threads in a C program. "

In any event, I would think having a bunch of OS processes would be _worse_ than having a bunch of OS threads.

re: Does Windows have a limit of 2000 threads per process?

Skywing — Sun, 31 Jul 2005 07:45:39 GMT

Actually, there's a new feature in XP/2003 that lets you (well, you as in the code that creates threads via NtCreateThread -- kernel32, in the case of win32 programs) specify a pointer to be auto freed by the kernel when a thread is terminated (released via NtFreeVirtualMemory).

The reason why the kernel doesn't automatically free user stacks in general is that the kernel didn't allocate them in the first place, so it doesn't necessarily know how to free them. The new auto stack free stuff works for all Win32 threads, which have stack allocated via a new block returned by NtAllocateVirtualMemory. You could conceivably have a thread that uses stack allocated by HeapAlloc(), or that's a global variable in a loaded image, or any number of other odd things, though, and in such cases you wouldn't want the kernel trying to free the stack with NtFreeVirtualMemory.

"an0nymo0us": For those things, you're pretty much stuck with using a dedicated thread pool or implementing them yourself (i.e. DNS queries).

re: Does Windows have a limit of 2000 threads per process?

TC — Sun, 31 Jul 2005 09:06:24 GMT

Hmm, am I the only person here with 30+ years experience who has never heard of continuation style programming? :-(

TC

re: Does Windows have a limit of 2000 threads per process?

Andreas Haeber — Sun, 31 Jul 2005 20:03:31 GMT

TC: See http://en.wikipedia.org/wiki/Continuation :)

re: Does Windows have a limit of 2000 threads per process?

Merle — Sun, 31 Jul 2005 22:36:45 GMT

TC: nope, you're not the only programmer who has not heard of continuation-style programming (although I'm only halfway to 30 in terms of professional experience).

However, thanks to the link from Andreas, I now know that I've used it. Ah, the joys of setjmp(). I learned so many brutal hacks from reading the source to BSD's telnet.

Like genget(), their happy command parser. I abused that in so many of my early C programs.

http://ftp.gcu.info/tuhs/PDP-11/Trees/2.11BSD/usr/src/ucb/telnet.c

re: Does Windows have a limit of 2000 threads per process?

Jawahar Mundlapati — Tue, 02 Aug 2005 10:18:54 GMT

You may check Kegel's excellent resource http://www.kegel.com/c10k.html

Maximum number of threads per process

Earning the next skiing holiday — Tue, 02 Aug 2005 13:45:52 GMT

Maximum number of threads per process

Earning the next skiing holiday — Tue, 02 Aug 2005 13:46:26 GMT

Non-blocking state machines

Craig Ringer — Tue, 02 Aug 2005 19:36:24 GMT

nikita, given your "not in C" comment with regards to threading alternatives, you might be interested in examining Twisted - it's a Python framework for deferred "reactor"-style execution. Some of the things people have done with it are pretty astonishing.

Speaking of which... I don't suppose anybody here knows if IronPython is going anywhere? Python on .net might be very interesting indeed.

Non-blocking state machines (2)

Craig Ringer — Tue, 02 Aug 2005 19:42:36 GMT

Actually, it appears that many of the criticisms leveled against async servers in C apply to Twisted too. I doubt it'd interest you much, though it's evidently very useful for many problems.

On the unanswerability of the maximum number of user interface objects a program can create

The Old New Thing — Fri, 01 Sep 2006 17:00:29 GMT

It's not like there's one number that controls everything.

Number of Maximum Thread on windows « Manish Pansiniya’s Blog

Number of Maximum Thread on windows « Manish Pansiniya’s Blog — Tue, 11 Mar 2008 09:43:00 GMT

PingBack from http://maniish.wordpress.com/2008/03/11/number-of-maximum-thread-on-windows/