Рассмотрим случай, когда процессор Cell / BE работает с несколькими контекстами / потоками SPU, когда это число превышает количество SPU в системе.Таким образом, планировщик Linux будет запускать заданный контекст до тех пор, пока не достигнет конца своего временного интервала, а затем обменять его для запуска другого контекста.
В нашей системе у нас есть некоторые контексты SPU, которые концептуальнов состоянии ожидания - мы не хотим, чтобы они работали сейчас, но мы хотим активировать их позже.Таким образом, мы бы хотели, чтобы планировщик Linux не менял их и не вытеснял другие контексты SPU, которые в данный момент работают.
Мы реализовали это состояние ожидания, выполнив контекст SPU для выполнения встроенной функции spu_readch, которая выполняетблокировка чтения в канале связи «Сигнал 1» от ППУ.Затем, когда мы хотим, чтобы контекст SPU активировался, мы записываем что-то в этот канал.
Таким образом, возникает вопрос: если контекст SPU ожидает блокирующего чтения в канале связи, откроется страница планировщика Linuxв любом случае, он будет добавлен в SPU, или планировщик распознает это и не будет публиковать его до тех пор, пока что-то не будет записано в канал?реализованы!)