Критический процесс

man nice
man chrt

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

pthread_setschedprio?

если процесс будет выполняться под рутом, можно поднять его «приоритет» (man nice, man sched_set_priority). но гарантию неразрывности тебе даст только real-time процесс с максимальным приоритетом в системе. надо не забывать тогда делать shed_yield, когда критический участок кончился. хотя, тут я, возможно, ошибаюсь.

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

отлаживаться можно с помощью man chrt.

Лучше белый на синем:
cls 15, 1

> надо не забывать тогда делать sched_yield, когда критический участок кончился

скорее sched_yield надо делать для прочих процессов

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

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

>man nice
man chrt

+ можно ещё использовать привязку твоего сервера к только одному из ядер, если у тебя система >=2 ядрам

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

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

и ещё: как вызвать sched_yield для другого процесса? приоритет изменить можно, а это-то как? :)

> когда он свой "критический" участок выполнит - нужно освободить ресурсы, иначе оно останется там навсегда.

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

смущает только "TCP сервер", точнее первой слово (TCP);

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

>Когда он получает запрос, то нужно, что бы он передал запрос как можно быстрее и после того, как получил ответ, передал назад(тому, кто послал запрос) тоже как можно быстрее.

Запрос-ответ большой?! Можешь посмотреть на флаг SO_OOBINLINE