Асинхронные задачи в С++11

Есть возможность сравнить на вашем же железе с реализацией std::async от Microsoft? В MSVC async работает поверх Parallel Patterns Library и не порождает много лишних потоков.

У меня получились другие результаты:
MSVC v12:

test_act 327.7 OK
test_async 306.7 OK

GCC 4.8.1

test_act 379.4 OK
test_async 337.2 OK

Параметры:

#define N_SIZE 10000000
#define N_THREADS 7
#define N_PARALLEL 73

Судя по этим результатам, стандартная реализация всегда чуть лучше.

Ошибки:
1. Вы принудительно заставили запускать async задачи в отдельных потоках. В вашей задаче нет смысла запускать потоков больше, чем кол-во процессоров в системе. Не стоит принудительно пихать
2. Следовало разобраться почему SIGSEG при захвате в лямбде, а не пихать tuple, код был бы заметно короче, для этого надо использовать std::decay.
3. Опять же нарушаете стилистику, чем вам std::future не угодил, а точнее std::promise, интерфейс был бы стандартный, да не изобретали бы велосипед с возвратом значения.
4. просто ужасный рабочий цикл, чрезмерно переусложнён.

По коду вывод один: Нужно знать не только объекты стандартной библиотеки, но и уметь ими правильно пользоваться. А вот с использованием у вас просто никак.

Правильнее было бы сделать отдельно очередь с 3мя методами: void push(task), bool pop(task&), void notify_exit(). notify_exit пробуждает все потоки в очереди и они возвращают false иначе pop висит до посинения, пока не придет задача. И не пришлось бы городить такой сложный огород.

По поводу этого:

template <typename T, typename ... Args>
  std::shared_ptr<task<decltype(&T::operator())>> make_task(T func, Args ... args )
  {
    return std::shared_ptr<task<decltype(&T::operator())>>(new task<decltype(&T::operator())>(func, args ...));
  }

Зачем использовать decltype(&T::operator()) в двух местах, если же выше у Вас написано:

template <typename T>
  class task
      : public task<decltype(&T::operator())>
  {
  };

Или я что-то не понял?

Главный цикл дочернего потока контролируется атомарной переменной (по идее достаточно было объявить ее volatile, так как тут нет состояния гонки, главный поток в нее только пишет, а дочерние только читают)
volatile в C++ никак не связан с многопоточностью и атомарностью.
Состояние гонки всегда есть, если в общие данные пишет хотя бы один из потоков, когда другие их читают или пишут. Помимо этого, стандартные атомики (не relaxed) влекут за собой acquire-release семантику и устраняют memory reordering, так что они не только ради атомарности нужны.

особой связи с мульти-тредингом я как-то в коде не вижу — наверно около 80% кода имплементят std::function.
оставшееся thread pool (который называется почему-то control).
думаю чтобы было ОК для «изучаем C++11» надо сделать следющее:
1) все что связано с «описаниями» тасков перевести на std::function, лямбды никуда от этого не пропадут и опыт их использования. написание своего std::function — это целая тема и не связана с асинхронностью.
2) выпилить std::cond и std::mutex для каждой задачи, список тасков может быть просто списком std::function. создавать тысячи или миллионы мутексов — как минимум странно, а в реальной жизни уж очень накладно.
3) попробывать упростить класс control, в нем «много пены»
4) упростить main — зачем ждать окончания каждого таска индивидуально? ждите пока тред пул не станет пустым или расширте интерфейс и дайте таскам приоритет/порядок исполнения. иначе получается что логика тред пула перекочевала в main.

в результате код уменьшится раз так в 5 и C++11 усвоится лутше. а тему «как самому сделать std::function» лутше изучать отдельно, там выше крыше своих хитростей.

Интересно, а есть люди, которые используют для этой цели Grand Central Dispatch не на OSX или iOS?