Am 12.05.2011 06:47, schrieb Daniel Gibson: > Am 12.05.2011 06:33, schrieb Jonathan M Davis: >> On 2011-05-11 21:14, dsimcha wrote: >>> I'm thinking about ways to remove the global lock from the garbage >>> collector for most small allocations. I'm basically thinking of making >>> the free lists thread local. Every scheme I can come up with that >>> doesn't require a radical overhaul of the current implementation >>> requires every thread having a unique ID. I want to do this as simply >>> and efficiently as possible, preferably using dense integers. Is it >>> reasonable to assume that no program will ever need more than 2 ^^ 16 >>> thread (about 65,000) simultaneously so that I can store these indices >>> as ushorts? If a program creates a lot of short-lived threads, the >>> indices will be recycled, so having a huge number of threads >>> non-simultaneously is not a problem. >> >> I don't think that you can legally create that many threads on a typical OS. >> I'd have to check, but as I recall, the typical limit is much lower than >> that >> - still in the tens of thousands, I think, but not that high. >> >> - Jonathan M Davis > > On Windows you get a DWORD (32bit int AFAIK) from GetCurrentThreadId(), > so that seems to be a technical limit there. > On Linux there's pthread_t which seems to be a 32bit uint on x86 and > 64bit ulong on amd64. > > However, see: > http://stackoverflow.com/questions/344203/maximum-number-of-threads-per-process-in-linux > It seems like it's limited by the available stack space (especially on > 32bit systems) > Similar on Windows: > http://blogs.msdn.com/b/oldnewthing/archive/2005/07/29/444912.aspx > > Cheers, > - Daniel
Also: http://www.sgi.com/products/servers/altix/uv/configs.html You can actually buy systems with 2048 Cores (AMD64 architecture even) and, thanks to Hyperthreading, 4096 threads (that may run at the same time) that run Linux. I think it isn't *that* unrealistic to have more than ushort.max Threads on such a beast.
