Better yet, change the logic of your application to make parallel_for invocations one after another in the same thread. Or consider using tbb::pipeline with the parallel_for in question placed inside a serial filter.
I have some questions to you JMB.
-How do you determine which job is more important - is it strictly by the order of start? What if two paralleljobs are started at nearly the same time, and so race for priority?
- When a master thread is unable to start the job because a previous one is not complete yet, what should this thread do ideally - just wait for its turn, delegate job submission to some other thread and continue asynchronously, or maybe help processing the currently running job?
It does not at all sound application specific :) It sounds like a somewhattypical pipeline with 3 stages: a list is produced, processed, and sent to a sink. The processing takes most of time, and independent pieces can be processed simultaneously (and in your case, processing also contains internal parallelism that you exploit with parallel_for). If the requirement to produce the list in different threads is not essential, I would recommend looking into tbb::pipeline, or maybe tbb::graph preview feature. And in any case, separation of processing and output, if possible, is a right thing to do. Great that the discussion helped you to find a good solution :)