Что-то я психанула...)))
Никакие мьютексы не нужны. Просто перед обработкой событий на сокетах сохранять текущее время, а при чтении/записи проставлять его, а не получать каждый раз вызововом time()

Главная проблема сисколлов в том, что приходится переключаться из режима пользователя в режим ядра. Однако, надо учитывать, что не все функции libc внутри себя дёргают сисколлы (например, какому-нибудь strlen ядро нафиг не нужно, malloc дёргает сисколлы только когда хочет увеличить кучу процесса). В случае time, конечно, сисколл будет.

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

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

man vdso

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

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

mutex не обязательно должен быть объектом ядра. Чисто технически их можно реализовать на 90% в userspace, от ядра потребуются только сисколлы для усыпления-пробуждения потоков (чтобы не крутить зря циклы ожидания). При этом:

1) Захват свободного мьютекса и освобождение мьютекса, который никто не ждёт, может быть произведён без обращения к ядру (не надо ни засыпать самому при захвате, ни пытаться пробудить другие потоки при освобождении)

2) Некоторые реализации перед тем как уснуть в ожидании мьютекса крутят некоторое количество busy loop ожидания - на многоядерной системе это может оказаться выгоднее (поток на соседнем ядре освободит мьютекс быстрее, чем займут времени сисколлы усыпления и пробуждения).

Однако, конкретная реализация pthread может не использовать эти возможности. Тут я уже не знаю... Я только знаю, что снизить стоимость mutex можно.

Главная проблема сисколлов в том, что приходится переключаться из режима пользователя в режим ядра. Однако, надо учитывать, что не все функции libc внутри себя дёргают сисколлы (например, какому-нибудь strlen ядро нафиг не нужно, malloc дёргает сисколлы только когда хочет увеличить кучу процесса). В случае time, конечно, сисколл будет.

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

Есть ещё VDSO.

time() по идее реализован с помощью __vdso_time() и должен работать значительно быстрее, чем «полноценный» сисколл.

time() по идее реализован с помощью __vdso_time() и должен работать значительно быстрее, чем «полноценный» сисколл.

Сделала гарантированно 1 вызов time() на цикл обработки событий на сокетах. При таких цифрах думать о реализации уже не имеет смысла

Два чая этому анонимусу.

В линуксе в glibc так и сделано — сначала попытка поспинлочиться через атомарный CAS, потом сисколл futex() для блокировки.

Но да, с учетом vdso time будет работать даже быстрее пары циклов спинлока из мьютекса, не говоря уже о вызове futex(), который будет дёргать планировщик.

мне одному кажется что этот велосипед уже давно превысил сложность буста ?

мне одному кажется что этот велосипед уже давно превысил сложность буста ?

Про мой софт вцелом или сискол time()?

один сискол не может сравниваться с бустом, конечно же про ваш софт в целом

и регулярно проходится по массиву соединений в поисках тех которые нужно отвалить по таймауту.

this. оптимизируйте этот кусок, а не ловлю блох с таймером

один сискол не может сравниваться с бустом, конечно же про ваш софт в целом

Я уже прошлась по всем граблям что только можно, просто соглашусь с вами.

this. оптимизируйте этот кусок, а не ловлю блох с таймером

Я еще не оптимизировала этот участок. Конечно же просто обход по массиву не оставлю и смотрю в сторону динамических структур из STL. К сожалению, я только недавно начала изучать C++ и вижу как много потеряла оставаясь на голом С.

К сожалению, я только недавно начала изучать C++ и вижу как много потеряла оставаясь на голом С.

А как много ты потеряла не пиша на лиспохацкеле!

А как много ты потеряла не пиша на лиспохацкеле!

Если отбросить сарказм, то я говорю о стоимости результата выраженной, как в минимум, в трудозатратах. Кто-то за 3 дня нафигачит то что я делаю уже 2 недели в режиме обучения. Это очень напрягает и на каждом этапе изчения вопроса говоришь сама себе «%*ть, да я же уже переписала этот участок за день, оказывается что тут можно проще и за час!»

бросай эту хрень, пошли девок портить ))

писать писать на язык Ада?

будешь писать на язык Ада?*

тут можно проще и за час!

на лиспохацкеле можно вообще ничего не писать, там уже всё есть.

man vdso

закапывают его... не взлетел, что неудивительно. удивительно то, что понадобилось 10 лет чтобы дошло.

Пришёл сюда, чтобы написать про vdso.