Newsgroup: it.comp.os.linux.development
Titolo: linux threads

ciao ragazzi, ho un problema..
ho un codice c (parallelo, che usa MPI..) che gira tranquillamente su piu'
macchine..
macchine alpha con Linux Red Hat..
se nello stesso codice inserisco dei thread per far fare a loro parte del
lavoro complessivo,
mi da errore nei conti..
i thread partono, senza problemi, e funzionano, tranne che salta tutto in un
punto ("killed by signal 8"??)..
in un accesso alla memoria..
se elimino quell'accesso, che senza i trhead funziona benissimo,ndr,
funziona tutto anche coi thread..
non so se  sono stato chiaro..
c'e' qualcuno qui che ha esperienza coi thread, in particolare su come
accedono alle strutture dati?
c'e' qualche differenza con l'accesso "normale"?
grazie
ciao
Giorgio
ps.per le risposte in e-mail, togliete il _NOSPAM, grazie

 c'e' qualche differenza con l'accesso "normale"?
In  teoria no. L'accesso  avviene normalmente. Il  problema e`  che piu`
thread potrebbero accedere nello stesso momento agli stessi dati. Se gli
accessi sono  solo in  lettura non  c'e` problema,  ma se  avviene anche
qualche scrittura...
Devi usare mutex o semafori per regolare l'accesso ai dati condivisi, e`
l'unico modo per assicurarne la consistenza.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Carpe diem, quam minimum credula postero. (Q. Horatius Flaccus)

 ha scritto nel messaggio
news:9qk92i$2vb$1...@dreamland.darkstar.net...


 thread..o no?
attento: il vantaggio dei thread su un monoprocessore e' solo la 
maggior "responsivita'" del programma, non un incremento delle 
prestazioni, anzi...

ok...
1° thread
void *calcolaEX(void *arg)
{
 void *ppp=NULL;
 do
 {
  sem_wait(&sem2);
    if(fine==1) break;
 for( I=Imina;I<Imax;I++)
  for( J=1;J<JM-1;J++)
   for( K=1;K<KM-1;K++)
      {
           EX[I][J][K]=EX[I][J][K]*C1[I][J][K]+(HZ[I][J][K]-HZ[I][J-1][K])*
\
         C2[I][J][K]+(HY[I][J][K-1]-HY[I][J][K])*C2[I][J][K];
            }
    sem_post(&sem3);
    printf("%d--%d :: STOP EX\n",myrank,STEP);
 }
 while(1);
return(ppp);
}
2° thread:
void *calcolaEY(void *arg)
{
 void *ppp=NULL;
 do
 {
  sem_wait(&sem1);
   if(fine==1) break;
 for( I=Iminb;I<Imax;I++)
  for( J=0;J<JM-1;J++)
  for( K=1;K<KM-1;K++)
   {
      EY[I][J][K]=EY[I][J][K]*C1[I][J][K]+(HX[I][J][K]-HX[I][J][K-1])* \
         C2[I][J][K]+(HZ[I-1][J][K]-HZ[I][J][K])*C2[I][J][K];
        }
    sem_post(&sem4);
    printf("%d--%d :: STOP EY\n",myrank,STEP);
}
while(1);
printf("ESCO EY\n");
return(ppp);
}
3° thread
void *calcolaEZ(void *arg)
{
 void *ppp=NULL;
 do
 {
  sem_wait(&sem5);
    if(fine==1) break;
 for( I=Iminb;I<Imax;I++)
  for( J=1;J<JM-1;J++)
     for( K=0;K<KM-1;K++)
  {
        EZ[I][J][K]=EZ[I][J][K]*C1[I][J][K]+(HY[I][J][K]-HY[I-1][J][K])* \
           C2[I][J][K]+(HX[I][J-1][K]-HX[I][J][K])*C2[I][J][K];
      }                         //          |-----(questo J-1 lo incasina!)
    sem_post(&sem6);
}
while(1);
printf("ESCO EY\n");
return(ppp);
}
main()
{
......
......
sem_post(&sem1);
sem_post(&sem2);
sem_post(&sem5);
....
....
sem_wait(&sem3);
sem_wait(&sem4);
sem_wait(&sem6);
....
...
fine=1;
...
}
l'errore e':
loader[fxxx12]: process 0 (10473) killed status 0xb
loader[fxxx13]: process 1 (8270) killed status 0xb
loader[fxxx12]: process 0 (10479) exited status 0x0
loader[fxxx13]: process 0 (8276) exited status 0x0
prun: no core file to analyse
prun: no core file to analyse
prun: process 10473 killed by signal 11
bah!
grazie
Giorgio
"noname" <non...@noorg.boh> ha scritto nel messaggio
news:1217540.D...@iol.it...


 return(ppp);
non si esce cosi' da un thread. devi usare pthread_exit()
e cio' in tutti e tre i casi.
inoltre, nel tuo caso basta un pthread_exit (NULL), eliminando ppp

 prun: process 10473 killed by signal 11
Bene, siamo  passati a SIGSEGV. Con  tutti gli array che  manipoli direi
che c'e` qualche indice che sconfina.
Se usi  malloc per creare gli  array prova a compilare  con -lmcheck. Se
usi array statici, passa a quelli  dinamici :) In questo modo puoi usare
mprobe per fare espliciti controlli sulla consistenza della memoria.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Quando un uomo porta dei fiori a sua moglie senza motivo, 
un motivo c'e`.

 thread..o no?
Dipende da che thread usi. Alle variabili condivise deve accedere un solo
thread per volta. Naturalmente la cosa non e' idilliaca ma non c'e' niente
da farci. 
--
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.mascanc.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! Heavy Metal Or No Metal At All! Whimps And Posers Leave The Hall !>-
 	 			Manowar - Metal Warriors

       }                         //          |-----(questo J-1 lo
incasina!)------------------------<<<<<<<<<<<<<<<
E' QUI IL PROBLEMA!!!


 e cio' in tutti e tre i casi.
Indifferente


 Indifferente
non costruirei un'applicazione mission critical sopra questa 
tua convinzione (e neanche una normale)



Da man pthread_create(3):
   The new thread terminates either explicitly, by calling
   pthread_exit(3), or implicitly, by returning from the start_routine
   function.  The latter case is equivalent to calling pthread_exit(3)
   with the result returned by start_routine as exit code.

 ha scribite:
[...]
Per favore, non riportare tutto il testo del messaggio a cui rispondi,
ma solo le parti necessarie. E scrivi il tuo testo *sotto*, altrimenti
si fa fatica a leggerti.
Grazie. :-)
-- 
Saluti,
    Mardy
http://castellina.org/interlingua

condivisi, e` l'unico modo per assicurarne la consistenza.
Non basterebbero anche delle sezioni critiche?

 Non basterebbero anche delle sezioni critiche?
? Cosa vuoi dire? E' proprio per la protezione delle sezioni critiche che si
usano queste primitive di sincronizzazione. O forse intendevi i monitor?
--
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.mascanc.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! God Knows How Long I Tried To Change Fate !>-
  		Blind Guardian - Mordred's Song

> Non basterebbero anche delle sezioni critiche?
GC> ? Cosa vuoi dire? E' proprio per la protezione delle sezioni critiche che si
GC> usano queste primitive di sincronizzazione. O forse intendevi i monitor?
No,  si  riferiva  ad  oggetti  del  kernel di  Win32  (che  non  sono
strettamente  necessari come  fai  notare  tu, ma  a  redmond non  son
contenti se  non reinventan l'acqua calda...)
--
Gian Uberto| main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Lauri      |                        David Korn, 1987 ioccc best one liner 
(aka saint)|-------------------------------------------------------------------
em@ail: 
sa...@eng.it
 ( vedere X-nospam nello header - see X-nospam in header )

intendevi i monitor?
Nulla, nulla. Riflesso condizionato da programmazione Windows :) (in cui 
esiste un oggetto di sincronizzazione chiamato appunto Critical Section, 
generalmente più rapido dei Semaphore se si tratta di sincronizzare 
unicamente thread dello stesso processo)