Hallo ! Ich schreibe gerade mein erstes Kernelmodul und habe ein Verständnisproblem mit der Funktion wait_event_interruptible_timeout() - speziell mit dem zweiten Parameter 'condition'. Der Literatur entnehme ich, dass beim Schlafengehen geprüft wird, ob die Bedingung 'condition' (in meinem Fall buffer_empty() = true) tatsächlich erfüllt ist, um Race-Conditions vorzubeugen. (z.B. Linux-Gerätetreiber 2.Auflage, S.308-310) Teil meines Moduls im Pseudocode: interrupthandler() { lese_zeichen_von_gerät(); schreibe_zeichen_in_puffer(); wake_up_interruptible( &wait ); } ioctl_lesen() { while ( weniger als 30 zeichen empfangen ) { wenn (!buffer_empty(buffer)) lese zeichen; sonst wait_event_interruptible_timeout( wait, buffer_empty(buffer), 100 ); } } Meinem Verständis nach soll nun wait_event_interruptible_timeout() noch EINMAL nachschauen, ob der Puffer wirklich leer ist und sich dann schlafenlegen bis entweder das Timeout eingetreten ist oder sie vom Interrupthandler mit wake_up_interruptible() wieder aufgeweckt wird. Das tut sie aber nicht. Es scheint als ob ständig nachgeschaut wird ob buffer_empty() wahr wird und wake_up_interruptible() völlig wirkungslos ist, da erst nach dem Timeout zurückgekehrt wird. Bevor das Timeout abgelaufen wäre, hat der Interrupthandler schon ca. 10mal ein wake_up gesendet. Als Condition habe ich auch schon !buffer_empty() ausprobiert - was letzlich zwar erfolgreich ist, aber nicht das ist, was ich will. Auch hier wird STÄNDIG geprüft, ob !buffer_empty erfüllt ist. Denn es wird zurückgekehrt, wenn ich wake_up_interruptible() im Interrupthandler deaktiviere. (Dass zwischenzeitlich der Puffer doch wieder gefüllt wurde, ist äußerst unwahrscheinlich). Wäre sehr schön, wenn jemand Licht ins Dunkel bringen könnte. Gruß Sascha