Sorry, I missed this thread (!) till now. On Mon, 2014-08-04 at 13:36 +0000, Dicebot via Digitalmars-d-learn wrote: > On Monday, 4 August 2014 at 05:14:22 UTC, Philippe Sigaud via > Digitalmars-d-learn wrote: > > I have another question: it seems I can spawn hundreds of > > threads > > (Heck, even 10_000 is accepted), even when I have 4-8 cores. Is > > there: > > is there a limit to the number of threads? I tried a threadpool > > because in my application I feared having to spawn ~100-200 > > threads > > but if that's not the case, I can drastically simplify my code. > > Is spawning a thread a slow operation in general?
Are these std.concurrent threads or std.parallelism tasks? A std.parallelism task is not a thread. Like Erlang or Java Fork/Join framework, the program specifies units of work and then there is a thread pool underneath that works on tasks as required. So you can have zillions of tasks but there will only be a few actual threads working on them. > Most likely those threads either do nothing or are short living > so you don't get actually 10 000 threads running simultaneously. I suspect it is actually impossible to start this number of kernel threads on any current kernel. > In general you should expect your operating system to start > stalling at few thousands of concurrent threads competing for > context switches and system resources. Creating new thread is > rather costly operation though you may not spot it in synthetic > snippets, only under actual load. > Modern default approach is to have amount of "worker" threads > identical or close to amount of CPU cores and handle internal > scheduling manually via fibers or some similar solution. I have no current data, but it used to be that for a single system it was best to have one or two more threads than the number of cores. Processor architectures and caching changes so new data is required. I am sure someone somewhere has it though. > If you are totally new to the topic of concurrent services, > getting familiar with http://en.wikipedia.org/wiki/C10k_problem > may be useful :) I thought they'd moved on the the 100k problem. There is an issue here that I/O bound concurrency and CPU bound concurrency/parallelism are very different beasties. Clearly tools and techniques can apply to either or both. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part