Does Windows have a limit of 200…

Often I see people asking why they can't create more thanaround 2000 threads in a process. The reason is not that there isany particular limit inherent in Windows. Rather, the programmerfailed to take into account the amount of address space each threaduses.

A thread consists of some memory in kernel mode (kernel stacksand object management), some memory in user mode (the threadenvironment block, thread-local storage, that sort of thing), plusits stack. (Or stacks if you're on an Itanium system.)

Usually, the limiting factor is the stack size.

#include <stdio.h>

#include <windows.h>

DWORD CALLBACK ThreadProc(void*)

{

 Sleep(INFINITE);

 return 0;

}

int __cdecl main(int argc, const char* argv[])

{

int i;

 for (i = 0; i < 100000; i++){

  DWORD id;

  HANDLE h = CreateThread(NULL, 0,ThreadProc, NULL, 0, &id);

  if (!h) break;

  CloseHandle(h);

 }

 printf("Created %d threads\n", i);

 return 0;

}

This program will typically print a value around 2000 for thenumber of threads.

Why does it give up at around 2000?

Because the default stack size assigned by the linker is 1MB,and 2000 stacks times 1MB per stack equals around 2GB, which is howmuch address space is available to user-mode programs.

You can try to squeeze more threads into your process byreducing your stack size, which can be done either by tweakinglinker options or manually overriding the stack size passed to theCreateThread functions as described in MSDN.

  HANDLE h = CreateThread(NULL, 4096,ThreadProc, NULL,

            STACK_SIZE_PARAM_IS_A_RESERVATION,&id);

With this change, I was able to squeak in around 13000threads. While that's certainly better than 2000, it's short of thenaive expectation of 500,000 threads. (A thread is using 4KB ofstack in 2GB address space.) But you're forgetting the otheroverhead. Address space allocation granularity is 64KB, so eachthread's stack occupies 64KB of address space even if only 4KB ofit is used. Plus of course you don't have free reign over all 2GBof the address space; there are system DLLs and other thingsoccupying it.

But the real question that is raised whenever somebody asks,"What's the maximum number of threads that a process can create?"is "Why are you creating so many threads that this even becomes anissue?"

The "one thread per client" model is well-known not to scalebeyond a dozen clients or so. If you're going to be handling morethan that many clients simultaneously, you should move to a modelwhere instead of dedicating a thread to a client, you insteadallocate an object. (Someday I'll muse on the duality betweenthreads and objects.) Windows provides I/O completion ports and athread pool to help you convert from a thread-based model to awork-item-based model.

Note that fibers do not help much here, because a fiber has astack, and it is the address space required by the stack that isthe limiting factor nearly all of the time.