Системные вызовы - это на самом деле просто переход вашего кода процесса из режима пользователя в режим ядра. Выполняемая задача вообще не меняется, она просто временно переходит в режим ядра для выполнения системного вызова, а затем возвращается в режим пользователя.
Задача может быть прервана планировщиком и перемещена на другой ЦП. , и это может произойти в середине обычного кода режима пользователя или даже в середине системного вызова.
Установив привязку задачи к одному ЦП с помощью sched_setaffinity(), вы удаляете эту возможность, поскольку даже если если задача прервана, у планировщика нет другого выбора, кроме как оставить его работающим на том же процессоре (он, конечно, может изменить текущую задачу, но когда ваша задача возобновится, он все равно будет на том же процессоре).
Итак, чтобы ответить на ваш вопрос:
обеспечивает ли тот же системный вызов принудительное выполнение кода пространства ядра в этом контексте процесса на том же ядре?
Да, это так.
Теперь, чтобы обратиться к комментарию @ Barmar : в случае системных вызовов, которые могут "спать", это не означает, что задача может Я изменю ЦП, если сходство не позволяет.
Что происходит, когда системный вызов спит, просто то, что код системного вызова сообщает планировщику: «эй, я чего-то жду, просто запустите другую задачу, пока я подожди и разбуди меня позже ". Когда системный вызов возобновляется, он проверяет, доступен ли запрошенный ресурс (он может даже точно сообщить ядру , когда он хочет разбудить), и если нет, он либо ждет снова, либо возвращается к пользовательскому коду, говоря " извини, ничего не получил, попробуй еще раз ". Разумеется, ресурс может быть сделан доступным по некоторому прерыванию, которое заставляет обработчик прерываний работать на другом процессоре, но это другая история, и это не имеет значения. Проще говоря: код прерывания вообще не запускается в контексте процесса. Что касается задачи, выполняющей системный вызов, ресурс просто волшебным образом появляется, когда выполнение возобновляется.