0

If I have a task which spawns, say, 10,000 async threads using c++11 async<> / futures. Does async automatically manage the number of concurrent threads?

Specifically, if I have an 8 core machine, would my program spawn 10,000 thread or would it be smart enough to queue them up into batches of 8 (or whatever is ideal for my machine)?

daj
  • 6,962
  • 9
  • 45
  • 79
  • `async` is kind of magic that you can't really control. If you need control, manage your own threads. You can then use `std::packaged_task` or some such to run stuff on them. – Kerrek SB Mar 31 '15 at 19:45
  • Are these threads very CPU intensive? FYI Take a look at this: http://stackoverflow.com/questions/3126154/multithreading-what-is-the-point-of-more-threads-than-cores – NathanOliver Mar 31 '15 at 19:47
  • @Kerrek I don't mind not having control so long as async is queueing the processes sanely and efficiently without further intervention (e.g. manually chunking based on the number of CPUs). – daj Mar 31 '15 at 19:49
  • 3
    Anyway you look at it 10,000 threads for 8 cores is ridiculous. the optimal number of thread given your task is far from that. Maybe 8, maybe 16, maybe 50, maybe a 100. but 10 000? Nope. ***The marginal benefit is zero, even negative.*** – UmNyobe Mar 31 '15 at 19:53
  • 2
    @daj: I guess "you can't really control" means that you also can't request any "as long as"s... – Kerrek SB Mar 31 '15 at 19:53
  • Only way to REALLY find out is to try it, but I expect it will create as many threads as it "needs", and that will have some overhead if the work is cpu-intensive (rather than, say, sitting waiting for network I/O). I did some measurement of that on a 100% cpu-bound task, and (from memory) 500 threads added a second or so on 1 minutes worth of work. That's the overhead of creating the extra threads, managing the threads throughout the program, scheduling them, and taking them down again when finished. Almost all of the additional time was spent in "system", not "user" time. – Mats Petersson Mar 31 '15 at 22:29
  • cppreference states that it will spawn 10000 threads. Didn't double-check the standard, but cppreference is usually reliable. Also this is related to the various `executor` proposals that are being discussed for c++17, IIRC at least one proposed to specify a default executor/thread_pool for async. – sbabbi Mar 31 '15 at 22:50
  • I guess my question was implicitly 'does async have built scheduler functionality' and it sounds like the answer is no. – daj Apr 03 '15 at 14:17

1 Answers1

2

This is a Quality of Implementation issue, not mandated by the standard.

However if any subset of threads block, the remaining threads must advance. So it cannot 'run 8, wait for them to finish, then start next 8'. It could monitor those threads for blocking and/or synchronized communication, and lacking those not lauch new threads. If they do block or read/write in a thread safe manner, keeping other threads suspended (or not started) indefinitely is not (I think) legal, and definitely a bad idea.

Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524