Es gibt aber eine einfachere Möglichkeit, wenn man die Stellen in den Programmquellen betrachtet, an denen von den Gerätetreibern schedule() aufgerufen wird. Hierbei ergeben sich zwei Anwendungen: Einmal wird von der Aktivität der Prozessor freigegeben (yield) und zum anderen aus irgendeinem Grund blockiert. Der Unterschied besteht darin, daß im ersten Fall der Prozeßzustand nicht verändert wird3.5. Ein Aufruf von schedule() sollte hier nur eine Prozessorfreigabe zur Folge haben -- l4_yield().
Wie im Abschnitt 2.5.2 (Ablaufsteuerung) beschrieben, kann aber auch der zweite Fall eintreten und die Aktivität den Prozeßzustand ändern, um zu blockieren. Das Deblockieren ist nur dann möglich, wenn der Prozeßkontext zuvor in eine wait queue eingekettet wurde.
Hier muß sich der Thread ,,schlafen legen`` bis das erwartete Ereignis eingetreten ist, also ein anderer Thread ,,aufweckt``. Dieses Verhalten läßt sich am besten mit einem kontextlokalen, binären Semaphore erreichen, der mit 0 inititalisiert wird. So kann über die Task-Struktur in schedule() der Semaphore angefordert und beim wake_up() auf die Waitqueue freigegeben werden.
An dieser Stelle zeigt sich ein Nachteil in unserer Umgebung: Die Task-Struktur umfaßt etwa 1700 Bytes und jedem Prozeßkontext wird eine Instanz zugeordnet. Andererseits werden im DDE nur wenige Elemente der Struktur wirklich benötigt -- es wird also Speicher ,,verschwendet``. Leider ist ein Aufräumen des task_struct Typen sehr aufwendig, wenn überhaupt machbar, da viele Funktionen, die als shortcuts dienen, bestimmte Felder der Struktur ansprechen und auch geändert werden müßten.
Die Änderungen würden sich stetig fortsetzen und die Anpassung an neue Kern-Versionen erschweren. An dieser Stelle muß noch nach einer passenden Lösung gesucht werden.