Поведение sched_yield - PullRequest
Новая
       8

Поведение sched_yield

11 голосов
/ 15 июня 2011

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

Кроме того, если у меня есть многоядерные процессоры, sched_yield выдаст потоки, работающие на всех ядрах, или только одно ядро.Например, у меня есть потоки 1, 2 и 3, работающие на ядре 1, и потоки 4, 5 и 6 на ядре 2, и если из потока 2 вызывается sched_yield, будут ли они заменены только на потоки 1 и 3 или 1,3, 4, 5 и 6 все возможно?Я спрашиваю об этом, потому что в .Net Thread.Yield уступает только потокам, работающим на одном ядре / процессоре.

Ответы [ 2 ]

4 голосов
/ 06 июля 2011

http://www.kernel.org/doc/man-pages/online/pages/man2/sched_yield.2.html

sched_yield () заставляет вызывающий поток освободить ЦП.Поток перемещается в конец очереди из-за его статического приоритета, и запускается новый поток.

Если вызывающий поток является единственным потоком в списке с наивысшим приоритетом в то время, он продолжит работупосле вызова sched_yield ().

sched_yield не является вызовом .Net и модель потоков / процессов отличается от.Планировщик Windows / .NET отличается от планировщика Linux.В Linux даже есть несколько возможных планировщиков.

Итак, ваши ожидания в отношении sched_yield неверны.

Если вы хотите контролировать, как выполняются потоки, вы можете привязать каждый поток к ЦП.Тогда потоки будут работать только на связанном процессоре.Если у вас будет несколько потоков, связанных с одним и тем же процессором, использование sched_yield МОЖЕТ переключиться на другой поток, который связан с текущим ЦП и готов к работе.

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

Если вы хотите получить полный контроль над тем, как работают потоки, вы можете использовать потоки RealTime.http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler - политики RT SCHED_FIFO и SCHED_RR.

0 голосов
/ 10 июля 2014

Зачем вам отказываться от процессора? Ну ...

Я исправляю ошибку в клиентском коде. По сути, они имеют общую структуру, которая содержит информацию:

  1. сколько монет на условном депозите - вернуть их
  2. сколько счетов в условном депозите - вернуть их

Вышеуказанное выполняется в процессе A. Остальная часть кода находится в процессе B. Процесс B отправляет сообщения процессу A для вычисления и возврата денег в условном депонировании (это торговый автомат). Не вдаваясь в историю , почему код написан таким образом, исходная последовательность кода:

(Процесс Б) отправить сообщение RETURN_ESCROWED_BILLS для обработки A отправить сообщение RETURN_ESCROWED COINS для процесса A Обнулить общую структуру

Это выполняется как:

(Процесс B): отправлять сообщения; обнулить структуру;

(позже .. Процесс А): получать сообщения; все поля в общей структуре равны 0; нечего делать;

упс ... деньги все еще на условном депозите, но процесс Код потерял эти знания. Что действительно необходимо (кроме массивной реструктуризации кода):

(Процесс B): отправлять сообщения; уступить ЦП;

(процесс А): определить депонированные деньги и вернуть; уступить ЦП; (можно просто перейти к концу временного интервала, особого метода не требуется)

(процесс B): обнулить общую структуру;

Каждый раз, когда у вас есть сообщения IPC и процессы, которые отправляют / получают сообщения, тесно связаны . лучший способ - это двустороннее рукопожатие. Тем не менее, существуют случаи (как правило, в результате плохой или несуществующей конструкции), когда необходимо тесно связывать процессы, которые, как предполагается, должны быть слабо связаны. Обычно производительность процессора - это хак, потому что у вас нет выбора. Добавление многоядерных процессоров является источником боли, особенно при переносе с одного ядра на многоядерный.

...