2012-04-09 11 views
5

Ho un pezzo semplice di lavoro deterministico che richiede solo tredici istruzioni macchina per completare. Poiché la prima istruzione prende un semaforo fatto in casa (spinlock) e l'ultima istruzione lo rilascia, sono al sicuro da tutti gli altri thread che girano sugli altri core mentre stanno tentando di prendere e dare lo stesso semaforo.Come posso evitare la prelazione del mio thread in modalità utente

Il problema sorge quando alcuni thread interrompono un thread che trattiene il semaforo prima che possa terminare la sua "sezione critica". Nel peggiore dei casi l'interruzione uccide il thread mentre si tiene il semaforo o come può accadere uno dei thread normalmente in competizione per il semaforo si dirama in codice che può generare l'interruzione causando un deadlock.

Non ho modo di sincronizzare con questi altri thread quando si diramano in quelle parti del codice che non posso controllare. Penso di aver bisogno di disabilitare gli interrupt come facevo nei miei vecchi giorni VxWorks quando stavo girando in modalità kernel. Sono sempre tredici istruzioni e sono sempre completamente al sicuro se riesco a ottenere tutte e tredici le istruzioni prima di dover onorare un'interruzione. Oh, sono tutti i miei dati interni, oltre al semaforo fatto in casa non c'è nulla che blocchi tutto il resto.

Ho letto diverse risposte che penso siano vicine. La maggior parte ha a che fare con chiamate di Critical Section sull'API di Windows (sistema operativo errato ma forse il concetto giusto). La maggior parte delle soluzioni sbagliate presuppone che io possa ottenere tutti i thread offensivi per utilizzare un mutex che creo con le librerie pthread.

Ho bisogno di questa soluzione in C/C++ su Linux e Solaris. domanda di

Johnny Crash è molto vicino prevent linux thread from being interrupted by scheduler

KermitG anche Can I prevent a Linux user space pthread yielding in critical code?

Grazie per la vostra considerazione.

+3

Utilizzare i mutex dalla libreria di thread (pthread) e leggere attentamente la documentazione. Non implementare le proprie primitive di sincronizzazione. La programmazione parallela è dura :) –

+1

@ RafałRawicki: "Non fare niente, perché è difficile". Forse ha solo bisogno di perché i mutex sono una schifezza. – Cartesius00

+0

possibile duplicato di [impedire che il thread di linux venga interrotto dall'utilità di pianificazione] (http://stackoverflow.com/questions/2595735/prevent-linux-thread-from-being-interrupted-by-scheduler) –

risposta

3

Non è possibile impedire il prelazione di un thread in modalità utente. Le sezioni critiche (e tutti gli altri oggetti di sincronizzazione) prevengono le collisioni dei thread, tuttavia non impediscono in alcun modo che vengano bloccati dal sistema operativo.

Se la vostra altra discussioni ramo in qualcosa il timeout, mentre quella qualcosa può portare ad una situazione di stallo - si dispone di un problema di progettazione.

Un design corretto dovrebbe essere il più pessimista: la pre-pubblicazione può avvenire ovunque per un tempo indeterminato.

+0

Ulteriori ricerche mi hanno portato a funzioni atomiche integrate fornite dai compilatori. Per esempio il manuale GCC 4.7, la sezione 6.52 tratta le operazioni atomiche. Credo di aver bisogno di un __atomic_thread_fence, ma non sono sicuro che ciò fornisca la protezione preventiva di cui ho bisogno. – wapadomo