насколько это адекватно?

https://software.intel.com/en-us/node/506100

^^ сабж

https://msdn.microsoft.com/ru-ru/library/windows/desktop/dd627187(v=vs.85).aspx

Треды нужны только для того чтобы получить пользу от многоядерности.

Про треды речь и не идёт

Треды, как обычные, так и легкие, это способ разделения к-л ресурса между разными задачами-контекстами, и это никак не связано с многоядерностью.

https://notabug.org/koz.ross/awesome-c#concurrent-and-parallel
https://github.com/fffaraz/awesome-cpp#concurrency

все же имеют, в контексте эффективного распределения вычислительных ресурсов, масштабируемости вычислений. Даже, уместней говорить не о многоядерности(как частный случай) а о многопроцессорности.

Готовые библиотеки: boost.fiber (на данный момент в буст не включена) и synca.

Есть мнение, что сопрограммы очень удобны, когда приложению нужно обслуживать множество параллельных и независимых активностей, при этом каждая активность предполагает:

• практически линейное выполнение прикладной логики;
• большую часть времени активность проводит в ожидании ответов от других частей приложения.

Грубо говоря, что-то вроде:

response process_request(request req)
{
  auto r1 = do_processing_stage1(req);
  if(!r1) return some_error(r1);
  auto r2 = do_processing_stage2(req);
  if(!r2) return some_error(r2);
  ...
  auto rN = do_processing_stageN(req);
  return result(rN);
}

Если такую обработку реализовать лоб-в-лоб на обычных потоках, то синхронные обращения к do_processing_stage1/.../stageN будут блокировать текущий поток. И для обслуживания сотен тысяч параллельных активностей потребуется создавать пул из большого количества рабочих потоков. Что дорого, неэффективно, а потому не есть гуд.

Если попытаться реализовать это дело на конечных автоматах, то можно получить лапшу вида:

class request_processor {
  state wait_stage1{ [this](stage1_res r) {
    if(!r) initiate_some_error(r);
    else {
      switch_to(wait_stage2);
      send_request_to_stage2(req_);
    }
  };
  state wait_stage2( [this](stage2_res r) {
    if(!r) initiate_some_error(r);
    else {
      switch_to(wait_stage3);
      send_request_to_stage3(req_);
    }
  };
  ...
  state wait_stageN( [this](stageN_res r) { ... }
  request req_;
public :
  request_processor(request req) : req_{req} {
    switch_to(wait_stage1);
    send_request_to_stage1(req_);
  }
};

Можно пытаться делать на механизмах future, но по сути это будет лишь более компактная и понятная запись конечного автомата:

void process_request(request req) {
  send_request_to_stage1(req_)
    .then( [=](stage1_res r) {
      if(!r) initiate_some_error(r);
      send_request_to_stage2(req);
    } )
    .then( [=](stage2_res r) {
      if(!r) initiate_some_error(r);
      send_request_to_stage3(req);
    } )
    ...
    .then( [=](stageN_res r) { ... } );
}

Тогда как линейная запись прикладной логики при использовании зеленых потоков намного проще в восприятии, реализации и сопровождении.

Но, насколько часто такие задачи встречаются и какие проблемы есть при использовании зеленых потоков — это уже другой вопрос.

Можно пытаться делать на механизмах future, но по сути это будет лишь более компактная и понятная запись конечного автомата:

то что Вы показали — это не механизм future. Вы просто конфигурируете объект, вешая на него коллбеки. Future — это объект, который принимает следующее сообщение после того, как превратился в значение. Это еще называется transparent future, но изначально термин future (а он появился в модели Акторов) означал именно это.

Меня впечатляет уровень вашей эрудиции, но сказать-то вы что хотели? Поспорить о терминах?

Треды нужны только для того чтобы получить пользу от многоядерности.

А вот и node-птушники подтянулись.

обидно, что происходит профанация. Примерно то же самое что с ООП. Сначала было ООП, а потом всякий мусор, все что не поподя под соусом ООП, и люди начинают думать, что Алан Кей придумал какую то парашу. Так же и здесь. Тут суть не в терминологических спорах, а в подмене понятий.

Простите, а не с очередным ли пришествием anonimous/somequest-а сейчас приходится общаться?

Concurrency is not parallelism. (c)

И ещё: визуализация concurrency vs parallelism.

это был аргумент Ad hominem?

Значит таки да. Извольте проследовать в игнор.

У меня так и помечен.

визуализация

Moderne Kunst :D

Вот тебе самые зеленые потоки изо всех возможных: http://software.schmorp.de/pkg/libcoro.html Scheduler на тебе.

Если хочется комбайна и фреймворка: https://github.com/mozy/mordor — испытанный хайлоадом, реально использующийся компанией-разработчиком.

почитал по Вашей ссылке эти все лозунги, не понял вот какие моменты. Во первых, конкурентность не исключает параллелизм, собственно на основе конкурентности можно строить параллелизм. Во-вторых, не понял сути наезда на интерфейсы. В-третих, вот это вообще ужасно:

Clear is better than clever. Reflection is never clear.

рефлексия — сердце ООП, его мощнейшая сторона, именно она позволяет строить абстракции состояния, по сути дела. Модель акторов — основа конкурентности (с которой, BTW, была слизана вторая, исправленная версия CSP, которая, в свою очередь задекларирована там как теоретическая основа), также рефлексивна.

Смешно выглядит, когда попытались «concurrency», а вышло «parallelism».

Concurrency is not parallelism.

Почему же на всех визуализациях параллельные линии(потоки) и почему длинна общего пути увеличивается с количеством потоков и почему 2 и более линии потока растут одновременно?

Это называется параллелизм.

конкурентность не исключает параллелизм

Конечно не исключает. Эти понятия просто ортогональны. Код может быть как конкурентный и не параллельный, так и параллельный и не конкурентный. Так же как и 2 оставшихся комбинации.

По поводу интерфейсов. interface{} says nothing: тут должно быть всё понятно. Это как void * с полностью утерянной мета-информацией. В частности о типе.

По поводу второго. Чем меньше интрефейс, тем более он полезный. Сам сравни io.Reader (в котором только один метод) с каким-нибудь монстром на десяток-два методов. Как часто ты можешь (ре-)использовать первое и второе?

Дело не в параллельных линиях, а в коммуникации между ними.

Ты его не модерируешь? :)

Это всё хорошо, только это обман. Любой блокирующий вызов - это ожидание какого-то события генерируемые не потоком исполнения. Т.е. залочить может только ОС, ибо блокировка в юзерспейсе не имеет смысла.

Но проблема в том, что блокирующие вызовы не отдают управление - поток, вызвающий их потерян для юзерспейса. Т.е. в любом случае потом создаваться будет и это не имеет смысла. Т.е. в твоём примере все стейджи - это сисколы.

Т.е. это имеет смысл только как обёртка вокруг ассинхронных операций. Но эти операции изначально не имеют контекста - они его передают и имеют события в юзерспейсе. Весь твой пример в реальном мире будет выглядеть как шедулер над ядерной ассинхрощиной.

В твоих сопрограммах реализация примитивна - все вызовы ридов/врайтом(это конечно верх маразма, но кого это волнует) и прочего заменяются на ассинхронные аналоги и все вызовы посылают в этот самый шедуллер, который связывает низкоуровневый идентифекатор и контекст потока. После завершения вызова - оно его возобновляет.

Т.е. это хранение тех же самых контекстов, что и в случае с «множеством потоков».

Конечно же - всё это обёртка и эмуляция того, что на уровне сишного кода есть уже десятки лет. При этом с тоннами оверхеда.

Без сопрограмм это реализует быстрее и проще, если использовать изначально ассинхронные подходы, ибо хранение того же контекста( в частности стека) - не нужно. Всё это можно хранить внутри класса, ибо класс, в отличии от функции - обладает состоянием.

Про треды речь и не идёт

Чем оно лучше и чем хуже пула нативных потоков?

ок

Царь и анонiмус в одном треде — это могло бы быть то еще шоу. Если бы не одно но: эти два уникальных персонажа пытаются излить свои потоки сознания на меня.

Шли бы вы, ребята, лесом.

Треды, как обычные, так и легкие, это способ разделения к-л ресурса между разными задачами-контекстами, и это никак не связано с многоядерностью.

Ядро это не ресурс. Ок

Ссылка годная, но я не сильно понял каким образом она относится к моей фразе о многоядерности.

А вот и node-птушники подтянулись.

Мимо. И вообще — с такой «аргументацией» сразу в игнор.

...оппа толстый модератор детектед...

с такой «аргументацией» сразу в игнор.

После «треды для многоядерности» - сразу на пересдачу.

Ядро это не ресурс.

Ядро - это не единственный вид ресурса. Более того, «многоядерность» - это всего лишь техническая деталь реализации SMP.

охереть это просто праздник какой-то. захожу на ЛОР, а тут сразу 2 баболки беспонтовые: царь (или косящий под него) и анонiмус! весна, обострения, торт

Где почитать про подобную архитектуру и зеленые потоки?

Первая ссылка в гугле по ключевым словам С++ сопрограммы.

Рутины придумали не в go, не нужно их везде называть горутинами, это корутины, а на нашем ещё могут называться сопрограммами.

Под С реализации есть, причём с разными подходами.

Не подскажу, к сожалению. Т.е. это результат накопления сведений из разных источников — статей, презентаций, обсуждений на форумах опыта использования разных подходов для разных задач, изучения документации к разным инструментам, общения с авторами некоторых инструментов и т.д.

Наверняка это все в концентрированном виде описывается, но ссылку на конкретную книгу или мануал не приведу.

Тогда как линейная запись прикладной логики при использовании зеленых потоков намного проще в восприятии, реализации и сопровождении.

Один мой знакомый node девелопер говорит что когда был callback hell то люди хоть немного думали прежде чем писать, и получалось не так плохо, а с появлением корутин в ноде они начали писать такое же говно как и писали когда были пхпшниками.

Я немного кодил под всякие twisted/tornado, и честно говоря не сильно понимаю о чем говорят люди ругающие их. Может я просто мало кодил.

Опыт из других языков программирования — это вещь хорошая. Но каким боком node/twisted/tornado к C++? С++ — это сильно небезопасный язык с кучей своих заморочек. Зеленые потоки способны количество этих заморочек увеличить. Ну или уменьшить :)

Т.е. это не маздайская поделка и полная паста отсюда https://github.com/CppCon/CppCon2015/blob/master/Presentations/C++ Coroutines... ? Бывает.

Ага, значит под каждым языком своя, абсолютно чужая другим языкам теория. Ок.

У Boost.Asio нет ничего общего с нодой и торнадо. Всевозможные варианты Futures в С++ не имеют ничего общего с одноименными штуками в жс. Ок.

КА он и в африке КА. Ок?

значит под каждым языком своя, абсолютно чужая другим языкам теория

Не под каждым, но бывает так. К примеру, то что Вы называете Futures, может и аналогичны в перечисленных Вами, но в более других языках они означают совершенно иное. К примеру

fetch(url).then(handle).then(smthElse)
//
fetch(url) handle smthElse

Да, с futures все немного странней. Мы говорили о КА vs coroutines в плане читабельности/понимабильности/сопровождабильности кода.

КА не так уже и плохи. Не понимаю почему они так трудно даются народу, и народ требует корутин.

Ага, значит под каждым языком своя, абсолютно чужая другим языкам теория. Ок.

Я не пытался в этом треде говорить про теорию. Надеюсь, с этим Ok.

На практике у callback-ов в C++ есть одна неприятная особенность по сравнению с callback-ами в языках со сборкой мусора: возможность нарваться на повисшие указатели и битые ссылки после того, как какая-то переменная, захваченная в callback-лямбде по ссылке, будет разрушена.

И эта особенность придает активной работе с callback-ами в C++ некоторый привкус, отсутствующий, насколько я помню, в JavaScript и Python.

Надеюсь, с пониманием этого тоже Ok.

Ну и, напоследок. Хотите блеснуть эрудицией или глубокими познаниями, ответьте что-нибудь путное ТС. Показывать мне, что я ничего не знаю, не следует, я сам в курсе. Ok?

Если Вы говорите об обычных коллбеках в стиле JS до промисов, то это действительно говно, и дело тут не в читаемости, хотя и в ней тоже. И сопрограммы тут не при чем особо, так как все равно используются те же промисы внутри. Самое хреновое в коллбечном стиле — дубовость. Н примеру, что-нибудь такое

fetch(url, onResponse)
// что если, я теперь захотел перед onResponse, сделать еще что-то?
// мне придется переписывать onResponse, вхерачивая туда еще один коллбек. А так я просто пишу
fetch(url)
 .then(somethingElse)
 .then(onResponse)
//а потом еще
fetch(url)
 .then(somethingElse)
 .then(somethingElseElse)
 .then(onResponse)

Кроме того, мы думаем о коде линейно, у нас не выворачиваются мозги наизнанку.

Конечно, это все далеко не идеально, но по сравнению с тем что было, это просто рай.

мне придется переписывать

ну и соответственно, переписывать все места где он используется. Я вообще недоумеваю, как какому-то дебилу пришло в голову начать так писать? И это все практикуется до сих пор.

у потоков 2 назначения:

а) способ разделения ресурсов между разными задачами-контекстами,

б) способ оптимизации скорости работы приложения за счёт многоядерности

Так и хочется снести по 4.2 или просто за тупняк.

Ну и, напоследок. Хотите блеснуть эрудицией или глубокими познаниями, ответьте что-нибудь путное ТС.

Я как раз и говорю о плюсах и минусах тредов и корутин, а так же об «альтернативных тредингу вещах» не забывая о старых добрых КА. Ок? Ок.

возможность нарваться на повисшие указатели и битые ссылки

Сэр не в курсе как с этим принято бороться в крестах? Это неок.

а) способ разделения ресурсов между разными задачами-контекстами

Это для тех кто не в курсе про «альтернативные» способы.

Один толковый товарищ говорил «A Computer is a state machine. Threads are for people who can't program state machines»

Конечно же есть годное применение тредам:

б) способ оптимизации скорости работы приложения за счёт многоядерности

Но оно только одно. Всё остальное от лукавого.

В треде выше уже были хорошие ответы. Попробую еще добавить кое-что. Например web/rpc серверы часто обрабатывают много IO запросов, в которых время которых мало тяжелой CPU-intensive работы, но зато одновременно происходит выполнение множества одновременных процессов для разных подключений. Процессов в широком смысле слова, а не процессов UNIX. Примером работы таких процессов есть много ожидания событий сети и парсинг форматов протоколов. Если говорить в числах, то например сервер мог бы обслуживать 10000 подключений и по сути только парсить сообщения и отправлять RPC дальше, больше ничего не делая. В таком случае количество состояния в каждом из таких «процессов» может быть например пару килобайт.

Можно использовать по потоку на процесс. Но системные потоки имеют большой системный стек и относительно высокую задержку планировщика когда процессов много.

Можно использовать пул потоков, но тогда сложно обойтись без множества блокировок для его реализации.

Можно распределять подключения между ядрами процессора на уровне дескрипторов входных сокетов, а после распределения обрабатывать каждый набор подключений одним потоком на одном ядре. В таком случае для каждого такого поток будет создан «селектор», в виде например epoll API для Linux. Это обьект, который в цикле выдает из ядра ОС сразу наборы сообщений напрмер о поступающих данных. Тогда в таком же цикле можно их обработать обычно без единой блокировки. Для удобства тут используют несколько техник, одна из них - зеленые потоки. Создается набор " контекстов". Контекст - стек (обычно меньше стандартного системного) и ссылка на функцию и ее аргументы. Потом они все «запускаются» в том смысле что каждой из нтх в цикле могут дать поработать пока они не запросят больше данных и тогда дают поработать следующей. Так они полностью в юзерспейсе переключаются путем сохранения и загрузки регистров процессора. Как только больше данных поступает из селектора - пробуждается зеленый поток и ему дают «поработать» до следующей зеленой блокировки - того момента как он запросит больше данных

Плюсы подхода - код зеленого потока выглядит как обычная функция с синхронным блокировками, стеки зеленых потоков минимальны, каждое ядро практически не блокируется под нагрузкой, используются все ядра из-за распределения дескрипторов подключений, каждый зеленый поток остается в том же самом системном потоке и часто ядре, улучшая утилизацию кешей. Кеши так же могут лучше работать из-за малых стеков

Вместо зеленых потоков можно использовать классы - машины состояний. Они будут еще компактнее и нету вероятности переполнить стек. Но они могут быть менее читаемы и в целом достаточно запутаны