Если это одна задача, которая ждёт окончания одной операции прежде чем приступить к другой - то в чём, блин, проблема от асинхронности?
Если одна задача (поток) ждёт окончания предыдущей операции прежде чем приступить к другой, то это синхронные операции. И тут конечно нет никаких проблем от асинхронности. т.к. её тут нет.
Можно, но как гарантировать что прям до диска всё дойдёт в нужном порядке, тот же posix aio это очередь которая обрабатывается несколькими нитями, кто первый встал того и тапки.
Я к тому, что в случае БД - системного ПО, всё гораздо сложнее.
Правильно! Только нужно копать глубже, сможет ли ваш асинхронный код на уровне языка программирования обеспечить упорядоченную запись. А как там на уровне ОС, контроллеров дисков? И если мы говорим о БД, то о всём этом нужно задумываться.
Ценник на самом деле не адекватный. ".. это как плевок в лицо народа..." - это конечно инфантил писал. Но когда на ОЗОН есть платы на этом же МК с плюс-минус теми же ценами и большей обвязкой, Микрон... Могли бы и демпингануть для большего охвата.
Я больше всё-таки про низкоуровневый код. Если Си становится тесным, то вполне можно перейти на С++, потихоньку добавляя разные возможности. Есть свои нюансы, но в принципе возможно. И тут большой плюс у C++ - какая-никакая но совместимость.
А в остальном согласен, С++ за время существования, такое легаси накопил, что очень сложно читать код реальных проектов, там разброс от фабрик-фабрик, до шаблоны-шаблонами погоняют. а ещё функциональщина. И это не говоря о библиотеках.
На Си тоже есть мастера жанра, которые изобретают ручное ООП, ещё и с макросами, но лично для меня классический процедурный код понятнее. Например, Linux-ядро - тупое как пробка.
Да нет, конечно. Другое дело, что нафига оно нужно в таком исполнении, если на том же ОЗОН валяются платы за +2000-5000 т.р. с отдельной флешкой. программатором и т.д.
ИМХО если требуется что-то низкоуровневое, то я бы предпочел чистый C, а не C++, из-за читаемости и "отлаживаемости".
Можно всегда на С++ в Си-стайл писать, используя только подмножество языка. Но у Си конечное есть своя ниша - старые/актуальные и новые проекты, типа Linux/DPDK/SPDK/кодеки/либы и т.д. Ну и конечно C ABI.
Конечно сложностей нет. Эвакуаторы же по воздуху передвигаются. Можно найти десяток крепких парней и скинуть машину в канаву. Только это не поможет, встала одна машина в потоке колом - пробка. И тут уже не важно электричка или нет.
Я видел такое, что вам, людям, и не снилось. Атакующие корабли, пылающие над Орионом; Лучи Си, разрезающие мрак у ворот Тангейзера. Все эти мгновения затеряются во времени, как... слёзы в дожде... Пришло время умирать.
Восемь лет назад, чтобы не "зашквариться" об Ардуино, я собирал под линуксом компилятор GGC с патчами для Tensilica Xtensa. Оптимизировал нашу прошивку, чтобы она полностью из RAM выполнялась, а не с флешки. Воевал с WiFi стеком, который цельнотянут с BSD. Эх, были времена...
Нет, это в вымышленном мире.
Ну если душнить, то я бы поспорил, что в ОС реализовали N:M. Последняя успешная попытка была в солярке. Сейчас все основные ОС сидят на один к одному.
Но в языках и библиотеках, конечно пытаются иммитировать.
А сопрограммы как выполняются?
Нет, это просто перекладывание задачи на ОС.
Может я и не прав, но оппонент скорее всего оперирует высокоуровневыми языками, где всё это скрыто под капотом. Поэтому и нет понимания.
Если одна задача (поток) ждёт окончания предыдущей операции прежде чем приступить к другой, то это синхронные операции. И тут конечно нет никаких проблем от асинхронности. т.к. её тут нет.
Можно, но как гарантировать что прям до диска всё дойдёт в нужном порядке, тот же posix aio это очередь которая обрабатывается несколькими нитями, кто первый встал того и тапки.
Я к тому, что в случае БД - системного ПО, всё гораздо сложнее.
Правильно! Только нужно копать глубже, сможет ли ваш асинхронный код на уровне языка программирования обеспечить упорядоченную запись. А как там на уровне ОС, контроллеров дисков? И если мы говорим о БД, то о всём этом нужно задумываться.
А кто гарантирует порядок в случае асинхронного I/o?
Ценник на самом деле не адекватный. ".. это как плевок в лицо народа..." - это конечно инфантил писал. Но когда на ОЗОН есть платы на этом же МК с плюс-минус теми же ценами и большей обвязкой, Микрон... Могли бы и демпингануть для большего охвата.
Я больше всё-таки про низкоуровневый код. Если Си становится тесным, то вполне можно перейти на С++, потихоньку добавляя разные возможности. Есть свои нюансы, но в принципе возможно. И тут большой плюс у C++ - какая-никакая но совместимость.
А в остальном согласен, С++ за время существования, такое легаси накопил, что очень сложно читать код реальных проектов, там разброс от фабрик-фабрик, до шаблоны-шаблонами погоняют. а ещё функциональщина. И это не говоря о библиотеках.
На Си тоже есть мастера жанра, которые изобретают ручное ООП, ещё и с макросами, но лично для меня классический процедурный код понятнее. Например, Linux-ядро - тупое как пробка.
Да нет, конечно. Другое дело, что нафига оно нужно в таком исполнении, если на том же ОЗОН валяются платы за +2000-5000 т.р. с отдельной флешкой. программатором и т.д.
Можно всегда на С++ в Си-стайл писать, используя только подмножество языка. Но у Си конечное есть своя ниша - старые/актуальные и новые проекты, типа Linux/DPDK/SPDK/кодеки/либы и т.д. Ну и конечно C ABI.
Не попал в пробку на много часов зимой?
Ну это математические рассуждения, очередь будет копиться. В идеале на сотни километров до, затора, но хоть едем.
А в реальном мире: - "Мне срочно надо!".
Конечно сложностей нет. Эвакуаторы же по воздуху передвигаются. Можно найти десяток крепких парней и скинуть машину в канаву. Только это не поможет, встала одна машина в потоке колом - пробка. И тут уже не важно электричка или нет.
Банковские приложения ещё верните, а то смазка демократии не работает!))
Восемь лет назад, чтобы не "зашквариться" об Ардуино, я собирал под линуксом компилятор GGC с патчами для Tensilica Xtensa. Оптимизировал нашу прошивку, чтобы она полностью из RAM выполнялась, а не с флешки. Воевал с WiFi стеком, который цельнотянут с BSD. Эх, были времена...
Хабр, что-то подглючивает... Поэтому в место нужной ветки вставлю сюда свои пять копеек.
Про cpu pinning, я всегда провожу тесты с ним для межроцессного взаимодействия, т.к.:
NUMA, если 2+ CPU - минимум в 2 раза всё тормознее.
AMD - нам подарил чиплеты, между чиплетами тоже всё плохо.
HT - тоже не равноценные.
Если дать на откуп планировщику, результаты плавают.
А в целом, статья отличная - торт!
На FreeBSD теперь тоже есть, т.к. толковый механизм и, например, firefox его использует для взаимодействия между процессами.