Sincronizzazione primitiva con IO / Kit

Question

Sto cercando una sincronizzazione di attesa / segnale primitiva IO / Kit di lavoro come:

Filettatura1: wait (myEvent) // Blocco Thread1

Thread2: wait (myEvent) // Blocco Thread2

Thread3: segnale (myEvent) // uscita uno dei Thread1 o Thread2

Questo non può essere fatto utilizzando un IOLock dal momento che le operazioni di blocco / sblocco sarebbero fatti da diversi thread, che è una cattiva idea secondo alcuni doc che ho letto.

Filettatura1, 2, 3 può essere thread utente o thread del kernel.

Mi piacerebbe anche dire avere un tempo facoltativa fuori con l'operazione di attesa.

Grazie per il vostro aiuto!

Answer 1

Si desidera la funzione IOLockSleepDeadline(), ha dichiarato in <IOKit/IOLocks.h>.

Si imposta un unico posto IOLock con IOLockAlloc() prima di iniziare. Poi, le discussioni 1 e 2 bloccare l'IOLock con IOLockLock() e subito abbandonano la serratura e andare a dormire chiamando IOLockSleepDeadline(). Quando il filo 3 è pronto, si chiama IOLockWakeup() (con oneThread = true se desideri solo svegliare un singolo thread). Questo cause thread 1 o 2 per svegliarsi e acquisire immediatamente il blocco (quindi hanno bisogno di sbloccare o dormire di nuovo).

IOLockSleep() funziona in modo simile, ma senza il timeout.

Si può fare qualcosa di simile utilizzando del IOCommandGate commandSleep () metodo che può essere più appropriato se il driver già è centrata intorno un IOWorkLoop.

Answer 2

La documentazione del metodo di IOLocks::IOLockLock afferma quanto segue:

Bloccare il mutex. Se il blocco viene mantenuto da qualsiasi thread, bloccare aspettando il suo sblocco. Questa funzione può bloccare e quindi non deve essere chiamato da livello di interruzione o mentre si tiene un blocco di selezione. Blocco del mutex ricorsivamente da un thread si tradurrà in stallo.

Così sarà certamente non bloccare gli altri thread (T1 e T2) fino al filo che tiene le uscite bloccarlo (T3). Una cosa che non sembra per il supporto è il timeout.