Имплементация гдеWesttrdпропущено...

Текущая имплементация aio для сокетов не является асинхронной
Имплементация где? И как asynchronous I/O (AIO) может быть не asynchronous?

AIO имеет ряд ограничений, и пока в стандартных ядрах нет полноценной реализации для сетевых сервисов. Вот последняя известная мне информация на сей счет:

http://lse.sourceforge.net/io/aio.html
What Does Not Work?

AIO read and write on files opened without O_DIRECT (i.e. normal buffered filesystem AIO). On ext2, ext3, jfs, xfs and nfs, these do not return an explicit error, but quietly default to synchronous or rather non-AIO behaviour (i.e io_submit waits for I/O to complete in these cases). For most other filesystems, -EINVAL is reported.
AIO fsync (not supported for any filesystem)
AIO read and write on sockets (doesn't return an explicit error, but quietly defaults to synchronous or rather non-AIO behavior)
AIO read and write on pipes (reports -EINVAL)
Not all devices (including TTY) support AIO (typically return -EINVAL)

Anatoly Moskovsky,

Мне тут известны 2 основных направления:
1. epoll для требовательных к латентности решений
2. libev и производные для требовательных к масштабируемости решений

Как правило, универсального ничего нет, решение затачивается индивидуально, особенно в специфичных проектах

самый производительный способAnatoly Moskovskyпропущено...

Это одно и то же направление.
2 - более высокоуровневое и кросплатформенное АПИ над 1 и аналогами в других ОСях.

Это и есть AIO (в широком смысле) про которое говорилось выше.
Т.е. фактически это (libev, libevent, boost.asio) самый производительный и по латентности, и по масштабируемости способ обмена данными по обычным TCP/IP сетям?


http://alexott.net/ru/cpp/BoostAsioNotes.html]http://alexott.net/ru/cpp/BoostAsioNotes.html] http://alexott.net/ru/cpp/BoostAsioNotes.html
westtrdВозможно даже выгнать ОС с этих ядер, при желании, важно чтобы irqbalance не использовал их, в остальном не страшно.
Вот как раз asio для не самых критичных по латенси компонентов подходит намного лучше того, что вы перечислили. Для критичных вещей я использую хранилища, аналогов которых в общеизвестных библиотеках нет , которые автоматически выравниваются по границе кеш линии процессора, реализуют безлоковую синхронизацию при необходимости.
А какой профит в % или абсолютных величинах это дает и как примерно это выглядит в реализации?
Тут речь идет не о процентах, тут речь идет скорее всего об узкоспециализированных решениях.
И, понятное дело, их применение должно быть обоснованным и уместным. В критических местах, там где битва идет за наносекунды, это становится необходимым.

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

самый производительный способ,

Размер страницы буфера подбирается.
Количество читателей не ограничено, но такие характеристики доступны только на выделенных ядрах в busy spin, при применении нотификаторов такое недоступно, само собой.

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

самый производительный способ,

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

Для курсоров барьеры не пользуются в принципе, алго позволяет это не делать.

ДохтаР,

Проприетарные алгоритмы, вся эта оптимизация устраняется на уровне внутренней логики.
Подробности закрыты.

И да, этот момент весьма тщательно оттестирован и работает.

самый производительный способ,

Согласен.
У меня получается что да.

самый производительный способ,

Это решение описано в специализированных проектах - курсор читателя если они не связаны логически, ДОЛЖЕН быть независимым, и оверхеда тут практически никакого

ДохтаР,

Ни первого, ни второго на читателе нет. Блокировок ресурса на курсоре не возникает, ибо курсор однопоточная сущность. В моей парадигме все блокировки контролируются писателем, но они минимизированы.

Копирования курсора тем более нет. Но это особенности имплементации, специфичные для решения.

ДохтаР,

Речь идет не об имплементации изменяемого хранилища, а об разновидностях FIFO очередей.