Newsgroup: it.comp.os.linux.development
Titolo: Mutexes & sleep

Ho un comportamento che non riesco a chiarirmi, magari qualcuno l'ha già
incontrato:
Ho una applicazione multithread ed un thread deve periodicamente sospendersi per
un certo tempo; per fare questo uso usleep (o sleep) ma ogni volta che il thread
principale fà il lock/unlock di un semaforo la sospensione dell'alltro thread
cessa e mi ritorna con codice -1.
Spulciando in giro ho visto che sleep(), usleep() e nanosleep()  mi ritornano
preventivamente in caso di Signal ricevuto, ma questo non sembra essere il caso.
Cosa stò sbagliando? Suggerimenti?
G.


lo standar posix prevederebbe pthread_delay_np, che sotto linux non c'è.
Sleep su molte implementazioni non fa dormire il thread ma tutto il task.
Ti conviene usare alarm, pause e intercettare SIGALARM.

On Mon, 17 Mar 2003 11:41:14 +0100, Gianandrea Gobbo 
was talkin'about:
#define IMHO

usleep e' obsoleta.
(u)sleep AFAIK sono implementate con SIGALRM e non sono una buona scelta nel
multithread. man 2 nanosleep
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
		-<! $>cd /pub	$>more beer !>-

 Ti conviene usare alarm, pause e intercettare SIGALARM.
Oddio, quando inizi a mischiare segnali e thread la cosa comincia a
diventare incasinata. E poi quasi tutte le funzioni di sleep ritornano
quando c'e' un segnale.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! Drink To Your Brothers Who Are Never To Fall, We Are Brothers Of Metal
  		Here In The Hall! !>- Manowar - Brothers Of Metal PT1

 quando c'e' un segnale.
sě, ma nei kernel 2.4 l'invio dei segnali č un po' uno schifo (e infatti
nei 2.5 molta roba č stata rifatta). La cosa piů sana č creare un thread,
installare in esso un signal handler e via con alarm. Altrimenti se tutti
i thread hanno la stessa maschera per la gestione dei segnali, non appena
uno riceve un segnale questo č visibile a tutti. E ovviamente poi la 
sleep esce.


Thanks.
Ci farò una prova.

 lo standar posix prevederebbe pthread_delay_np, che sotto linux non c'è.
pthread_delay_np non è previsto da POSIX. Il suffisso "_np" è
convenzionalmente usato per funzioni non portabili di una qualche
implementazione ('np' = "non portable").
Max

 sleep esce.
Il problema e' gestire i segnali asincroni. L'unico costrutto di
sincronizzazione async-safe sono i semafori. Cioe' hai bisogno di un thread
separato che raccolga i segnali in code ed eventualmente altro. Non e' la
cosa piu' semplice di questo mondo. E non penso proprio che possa produrre
delle tempistiche precise.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
        **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
 [cowo@braveheart cowo]$ make sex
    make: *** No rule to make target 'sex'.  Stop. 

 implementazione ('np' = "non portable").
ah sì? nel pdf di documentazione che ho letto io stava per not process....
non è che siano due cose simili....

 delle tempistiche precise.
non riesco bene a capire cosa vuoi fare. puoi essere un po' meno vago?

 non è che siano due cose simili....
Sullo standard non metto parola perche' non l'ho mai letto. Su linux il _np
indica non portabile. Ma effettivamente non vedo molto l'utilita' di un
simile significato in uno standard.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**


 non riesco bene a capire cosa vuoi fare. puoi essere un po' meno vago?
Vediamo:
Tutti i thread che devono dormire non possono bloccare dei segnali perche'
altrimenti le primitive di sleep ritornerebbero prima del tempo: quindi la
loro sigmask e' predisposta per ignorare cani e porci.
Quindi spawno un thread che intercetta tutti i segnali che mi interessano:
li prende e li mette in una (o piu') coda (gestita a semafori) in modo che i 
thread interessati possano pescarli quando hanno tempo. Solo che tutta
questa baracca non garantisce tempistiche precise. Insomma, il mix di
segnali e pthread e' tutto sommato una brutta bestia.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**


 loro sigmask e' predisposta per ignorare cani e porci.
ma allora il problema č che tu vuoi usare sleep quando invece dovresti
usare pause.
la butto lě: in ogni thread installi tanti handler, uno per ogni segnale
che vuoi intercettare e poi inizializzi una variabile che ti dice se devi
dormire o meno. Nei vari handler solo quello del SIGALARM puň modificarla
e tutti fanno le routine associate ai segnali. Nel codice che ha messo il
thread in pausa basta che fai qualcosa come
int sleep = 1;
...
while(sleep) pause();
...
...
void alarm_handler (int sigid) {
    ...
    sleep = 0;
}
Cosě ti becchi i segnali, il thread si sveglia, ma se non č stato
svegliato dal timeout allora torna a dormire.
L'unica cosa che puoi dire č che alarm prevede timeout dell'ordine di
secondi.
Altrimenti potresti fare con nanosleep, perché leggevo nella
documentazione:
       In  case  of  an  error or exception, the nanosleep system
       call returns -1 instead of 0 and sets errno to one of  the
       following values:
 
       EINTR  The  pause  has  been  interrupted by a non-blocked
              signal that  was  delivered  to  the  process.  The
              remaining  sleep time has been written into *rem so
              that the process can easily  call  nanosleep  again
              and continue with the pause.
Insomma, ti arriva un segnale e torni a dormire.

 thread in pausa basta che fai qualcosa come
No. Nei POSIX threads puoi definire una sigmask specifica per thread, ma
l'handler e' comune a tutto il pool di thread.
Mi viene in mente che un altro pattern applicato ricorrentemente e':
creare un nuovo thread, dedicato alla sola acquisizione dei segnali, che
loopa su una sigwait, in modo da ricevere in modo sincrono i segnali. I
segnali che interessano devono essere bloccati da tutti i thread.
Se ti interessano > dettagli le FAQ di comp.programming.threads sono molto
carine.
...
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail** 
-<! There are 10 kind of persons: who understands binary and who doesn't. !>-

 delle tempistiche precise.


 non riesco bene a capire cosa vuoi fare. puoi essere un po' meno vago?
Crei un thread separato in cui installi gli handler per tutti i segnali che
ti interessano. Ogni handler mette le informazioni sul segnale ricevuto in
code gestite con semafori. Tutti gli altri thread fanno riferimento a queste
code per ottenere i dati sui segnali ricevuti.
In alternativa si possono "sincronizzare" i segnali sempre creando un thread
ad hoc che loopa su una sigwait.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**


On Mon, 07 Apr 2003 12:52:26 +0000, Giuseppe Corbelli wrote:
non capisco da dove sia risbucato fuori il mio messaggio....
mah, sarà stato pan che ha fatto casino....

 mah, sarà stato pan che ha fatto casino....
Ops...
Mi pareva infatti di aver gia' risposto. Ma la mia memoria fa schifo :-)
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail** 
