- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
auto write = [&buf](future<int> size) -> future<bool> {
return streamW.write(size.get(), buf).then(
[](future<int> op){
return op.get() > 0; }); };
auto flse = [](future<int> op){
return future::make_ready_future(false);}; auto copy = do_while(
[&buf]() -> future<bool> {
return streamR.read(512, buf) .then(
[](future<int> op){ return (op.get() > 0) ? write : flse;}); });
///////////////////////////////////////////////////////////////////////////
int cnt = 0;
do {
cnt = await streamR.read(512, buf);
if ( cnt == 0 ) break;
cnt = await streamW.write(cnt, buf);
} while (cnt > 0);
Follow us!
Сама по себе идея восходит к МакКарти и его запланированому, но никогда не реализованому языку Слону, флюент логике, Остину и его курсу лекций "о том как совершать действия с помощью слов". Другими словами, о том, как програмно описать такие понятия как "принять обязательство", "сделать предложение" и т.д.
Тема вцелом интересная, и предлагающая очень нетрадиционный подход к написанию програм (полный отказ от описания структур данных - задача создания структур данных возлагалась бы на компилятор / интерпретатор, который бы исходя из ситуации сам подбирал бы нужную структуру, оперирование не предикатами / утверждениями а изьявлениями воли / пожеланиями).
Но в полном объеме система никогда не была воплощена, да и не понятно, как даже подступиться, но некоторые элементы приобрели определенную популярност, вот "будущие", "обещания", "ожидания", "уступки" и т.п. - что-то что разные языки в разной степени переняли от этих идей.
Что до семантики многозадачности: мне еще нигде не попадалась хорошая :) да и по отзывам специалистов, не понятно, что бы из себя представляла така семантика, что в ней должно быть, и какие концепции нужно выражать / какие строительные блоки нужны. Но все прогрессивное человечество семимильными шагами устремилось, так что рано или поздно, что-то будет.
это был всего лишь пример, но ты раскрыл тему: человеческой семантики прикрутить никто не может.
Ada была и остается самой успешной попыткой которую я видел. Когда-то давно нагуглил:
http://en.wikibooks.org/wiki/Ada_Programming/Tasking
и все еще пользуюсь как справочником по шаблонам синхронизации. Как на микро так и на макро уровне.
Очередь - это всего лишь деталь реализации. Причем достаточно низко-уровневая. И одной очередью дело редко заканчивается. Это почти RPC: содержимое очереди на высоком уровне можно описать как сериализованые вызовы функций.
Почитай по линку. Если я концепции из своей головы начну описывать, то это будет скучно и нечитабельно. Но в конце концов, оно маппится на Ada и да же тех же примеров приведенных уже достаточно.
Из высокоуровневого краем глаза видел akka. Ну и ФП, если его можно туда причислить.
Например, в Си-подобных языках одна из фундаментальных вещей - это отсутствие абстракции памяти, т.е. управление памятью открыто для программитста и предполагает, на уровне языка, Фон Ноймановскую програму, т.е. программу которая должна выполнятся в одном потоке. Это позволяет, например, сильно оптимизировать массивы, т.как не нужно их передавать по значению, а достаточно передать указатель на массив. Более того, на уровне языка даже нет возможности передать массив произвольной длины по значению.
Что делают в таких языках: начинают отчаяно отстаивать идею указателей, и придумывают всякие ухищения, как приготовить яйцо в микроволновке. Но я все это говорю не потому, что я знаю, как надо было бы сделать - я понятия не имею, а потому что так как оно сейчас, это совсем не хорошо.
Никогда не слышал.
> Это позволяет, например, сильно оптимизировать массивы, т.как не нужно их передавать по значению, а достаточно передать указатель на массив.
А где массивы передаются по значению?
Ну вот тут более-менее описано.
Я не знаю, где массивы передаются по значению, я это говорю не потому, что где-то уже лучше сделано, а потому что это серьезное препядствие с которым сталкивается любая система пытающаяся описать общение между одновременно выполняющимися задачами.
Бакус (тот самый в честь которого названа форма записи Бакуса-Наура) очень сильно ратовал за то, чтобы искать альтернативные решения. Но как-то чего-то пока никаких существенных наработок в этой области нет, ну или мне не известны.
> а потому что это серьезное препядствие с которым сталкивается любая система пытающаяся описать общение между одновременно выполняющимися задачами.
То есть сишка не может, и это плохо, а что никто другой тоже не может - как-то пофиг?
Так нифига и не понял про ноймана, наверно не судьба.
Другими словами: то что Си не может - это плохо, а то, что никто другой не может - это тоже плохо. Это ж открытая система, и хочется верить, что языки программирования, вообще не ограничатся только созданными за последние 60 лет. Скорее всего их будет больше и лучших.
Нойман описал компьютер как коробку с одним вводом и одним выводом (в то время как у параллельно выполняющейся системы есть много вводово и, возможно, выводов).
OpenMP - это про другое. Это не для того, чтобы "параллелить циклы", это набор примитивов для написания програм, которые могут выполнять несколько задач одновременно. То, что там есть какая-то возможность сделать выполнение цикла, в некоторых случаях параллельным - это второстепенная деталь.
Вот, что еще можно почитать по этому поводу (это одна из предполагаемых альтернатив).
Из всех языков, которые там перечислены, я пробовал (или вообще слышал раньше) только про Oz и VHDL. Исходя из чего могу судить, что остальные тоже, либо узко-специализированые, либо чисто академические языки.
Я лично хотел бы видеть в мейнстриме годную реализацию task-based concurrency.
В Go очень годно всё, в 1.2 вон сделали возможность вытеснения длинной вычислительной задачи на вызове функции. От длинных числодробильных циклов это, правда, не спасёт.
и реализацию библиотеки, в отличии от кейворда, можно легко заменить
можно записать как
Будет тоже самое. Они упоротые?
Ты уверен? Первое шедулится в юзерспейсе, второе в кернел-спейсе. Люди пишут ОС внутри ОС and we need to go deeper.
В данном коде это бесполезно, но если вокруг этого кода много другого асинхронного кода - это благое дело. И если ты думаешь что можно написать высоконагруженный сервер без асинхронного кода и если ты считаешь потоком меньше или больше неважно и ты их насоздаешь целый пул, сервер 128 гб RAM всё стерпит, то поздравляю: сам мудак. Сколько ты памяти сожрешь только на стек в каждом возможно неиспользуемым рационально сейчас потоке? Если ты правда Борманд - не обижайся.
Конечный автомат, сука! Повторяй по буквам!