Why cant I create 1 million threads?

[camel-man]

I have code written in java and I am fluxuating the parameters of how many threads I am creating, the OS accounts for threads up to 20,000 and I can see on the task manager that the number of running threads increases. Then how come when I put in 1 million the program still runs but the number of threads remains constant at the normal operating level? it doesn't go past the standard maintenace of 1000 threads running? I don't understand.

 

[.Scott]

You haven't specified which OS you're using, but there may be a (possibly undocumented) limit on the number of threads a single program can create - or on the number that can be reported by the OS.

It is uncommon for an application to spawn more than 100 threads at a time. And for most applications, creating that many threads would indicate a poor design.

 

[Borek]

Just because the OS shows thread number 20000 doesn't mean there are that many threads, chances are most earlier ones were long killed.

Switching is costly, having many threads can substantially slow down the computer, as CPU spends more time switching between threads, than doing the real job. That's why number of concurrent threads can be limited, like .Scott suggested. Those you tried to start can be in queue, waiting, or they were simply not started and ignored.

 

[phinds]

Excessive numbers of threads result in "thrashing" which is what Borek described. Operating Systems are designed to not allow unlimited thrashing and so will not attempt to run unlimited numbers of threads. I'm saying the same thing Borek said, just using more formal terminology.

 

[Borek]

Excessive numbers of threads result in "thrashing" which is what Borek described. Operating Systems are designed to not allow unlimited thrashing and so will not attempt to run unlimited numbers of threads. I'm saying the same thing Borek said, just using more formal terminology.

Thanks, sometimes I am limited by my English.

 

[SixNein]

Excessive numbers of threads result in "thrashing" which is what Borek described. Operating Systems are designed to not allow unlimited thrashing and so will not attempt to run unlimited numbers of threads. I'm saying the same thing Borek said, just using more formal terminology.

The processor state with each thread must be maintained as a scheduler switches them out to do work. To do a switch, the registers for the thread have to be saved. The kernel registers have to be loaded, the scheduler comes up with the next thread to get some time, the kernel registers have to be saved. The next thread's registers have to be loaded.

So as the number of threads increases, the computer spends more and more of its time exchanging registers instead of doing work.

 

[phinds]

So as the number of threads increases, the computer spends more and more of its time exchanging registers instead of doing work.

Exactly. The formal name for this process is, as you said before you edited you post, "context switching" and when it is done to excess it is called "thrashing". The name comes from the manual separation of grain kernels from their stalk by slapping them back and forth on stones, a process known as thrashing. Why this term is used to describe something that doesn't get any work done, or actually PREVENTS work from getting done, seems unclear since it does get work done. I think it's the moving back and forth part of the term that is what is being used to describe the computer process.

 

[.Scott]

The name comes from the manual separation of grain kernels from their stalk by slapping them back and forth on stones, a process known as thrashing. Why this term is used to describe something that doesn't get any work done, or actually PREVENTS work from getting done, seems unclear since it does get work done. I think it's the moving back and forth part of the term that is what is being used to describe the computer process.

"Thrashing" was originally applied to mainframe systems with disc drive - the kind of disc drives that resembled automatic washing machines in bulk and overall appearance. The thrashing could be easily seen and heard to the computer operator as system cause the read/write heads to position back and forth to widely (several inches) separated cylinders.

 

[D H]

Excessive numbers of threads result in "thrashing" which is what Borek described.

Not necessarily. For example, suppose each thread represents a remote connection of a person typing queries into some database. Almost all of the threads will be I/O suspended, waiting for slow human input. Only a small handful will be active, and most of those will be suspended as well, either waiting for the database or waiting for permission to access the database.

@camel-man, the reason you cannot create a million threads is stack size. Each thread has its own execution stack. The default with several Java Virtual Machines is 1024k per thread on a 64 bit processor. 1 million times 1024k -- that's a terabyte. You probably don't have that much disk space, period, let alone that much disk space set up as virtual memory.

 

[phinds]

Not necessarily. For example, suppose each thread represents a remote connection of a person typing queries into some database. Almost all of the threads will be I/O suspended, waiting for slow human input. Only a small handful will be active, and most of those will be suspended as well, either waiting for the database or waiting for permission to access the database.

Good point.

 

[SixNein]

Not necessarily. For example, suppose each thread represents a remote connection of a person typing queries into some database. Almost all of the threads will be I/O suspended, waiting for slow human input. Only a small handful will be active, and most of those will be suspended as well, either waiting for the database or waiting for permission to access the database.

@camel-man, the reason you cannot create a million threads is stack size. Each thread has its own execution stack. The default with several Java Virtual Machines is 1024k per thread on a 64 bit processor. 1 million times 1024k -- that's a terabyte. You probably don't have that much disk space, period, let alone that much disk space set up as virtual memory.

Good point, only the heap is shared in a multithreading environment.

There can also be price to pay on cpu cache performance if the code is large enough since those threads will trigger lots of cache misses.

 

[Baluncore]

The OS may well have a long queue of a million inactive threads waiting their turn. The report of 20,000 may be the number of threads loaded during the last sample time. With 1 msec allocation that time period would be 20 seconds. If the threads were all idle it might only take 50 usec to switch and check, that gives a sample reporting time closer to 1 second.

 

[Adyssa]

The pid of a process is just an incrementing integer, I get pid's of 20000 or so fairly often, but most of the processes that had lower pid's are long gone. I guess the OS just keeps incrementing until it's safe to start again at some lower number.