R: [bglug] Reagire al deadlock in multithtread app

[mlpita@bergamo3.it]

Potrebbe essere una soluzione, ma non mi sembra molto elegante.
Ciao, Diego

Alle 12:32, martedì 29 novembre 2005, Bruno Belotti - Udf.it ha scritto:
> forse una soluzione potrebbe essere quella di far generare
> un signal dal programma a bassa priorità verso quello ad
> alta priorità.
> Nel programma principale ci si aspetta un signal, che se non
> arriva dopo un certo tempo invalidi il semaforo e lo ricrei.
> Questo almeno in teoria potrebbe andare... cosa ne pensi?
>
> Br1
>
> -----Messaggio originale-----
> Da: bglug-bounces@lists.linux.it
> [mailto:bglug-bounces@lists.linux.it]Per conto di mlpita@bergamo3.it
> Inviato: martedì 29 novembre 2005 12.24
> A: bglug@lists.linux.it
> Oggetto: [bglug] Reagire al deadlock in multithtread app
>
>
> Ciao a tutti,
> Ho due programmi, uno ad alta priorità che deve sempre girare ed uno a
> bassa priorità che mostra i dati elaborati dal primo. I due processi
> comunicano con
> SharedMemory (shmget, shmat) con accesso sincronizzato da un Named
> Semaphore condiviso (sem_open, sem_post, sem_wait).
> Entrambi i processi hanno un thread timerizzato in cui leggono o scrivono i
> dati sulla SharedMemory. All' inizio ed alla fine della funzione
> "DoTimedWork" del thread vengono fatte la sem_wait e la sem_post.
> Nel caso che la seconda applicazione (visualizzatore) si impianti durante
> la lettura della memoria condivisa all' interno del blocco di sincronismo
> senza rilasciare il semaforo, come posso fare ad evitare che il primo
> processo se ne accorga ed invalidi il semaforo per poi ricrearlo?
> Ho cercato su internet ma non ho trovato nulla a riguardo, se qualcuno è in
> grado di aiutarmi....
> Grazie, Diego
>
> --
> Sito BgLUG: http://www.bglug.it
> Mailing list: http://www.bglug.it/list/bglug
> BgLUG-biz!: http://www.bglug.it/list/bglug-biz