Newsgroup: it.comp.os.linux.development
Titolo: thread, processi... o che altro?

Stavo pensando di sviluppare un'applicazione server (demone) che ha il
compito di controllare un certo numero di modem (gsm e non) con diverse
funzioni.
Ad esempio l'amministratore puo' configurare il sistema in modo che questo
"servizio" comandi 2 modem GSM in modalità ricezione sms. La funzione per il
contollo del modem è identica, dovrà aspettare i messaggi sms, e passarli al
"processo" principale, che li elabora e li salva da qualche parte.
Come mi consigliate di sviluppare la struttura? THREAD o PROCESSI?
E per lo scambio di dati tra il processo principale e quello figlio? Memoria
condivisa? O che altro è più adatto?
Grazie,
Marko

  Marko
ciao ...
-- 
#include <stdio.h>
int main(void){char c[]={10,65,110,116,111,110,105,111,32,98,97,114,98,111,110,
101,32,60,104,105,110,100,101,109,105,116,64,116,105,115,99,97,108,105,110,101,
116,46,105,116,62,10,10,0}; printf("%s",c); return 0;}

Grazie, mi studio per bene queste cose e poi sviluppo...
Pero' un mio amico mi ha detto di lasciar perdere i thread... secondo voi
come mai? (che non so quando lo risento)
Grazie
"Antonio barbone" <bar...@raffaello.home> ha scritto nel messaggio
news:slrnaujn6v...@localhost.bagnoli.home...


  Grazie
ciao ..



Perche' su Linux sono simulati usando i processi (creando un nuovo processo
con memoria interamente condivisa con il precedente).
Mi risulta anche che non siano completamente compatibili con lo standard
POSIX previsto per i thread, in partcolare per quanto riguarda la gestione
dei segnali.
Penso che globalmente la gestione di un sistema a preocessi sia piu'
semplice.

 semplice.
In compenso talvolta l'IPC e' molto piu' complicata. con i thread e'
decisamente banale.
HappyCactus che preferisce i thread
-- 
HappyCactus - Linux User #209744 - LFS User #6046 - >>> SMSPM1050 <<<
              YAGF Member Group >>> 
www.google.com
 <<<
Ci sono 10 categorie di persone al mondo: quelle che capiscono
il sistema binario e quelle che non lo capiscono.

 comunque dacci un occhiata e decidi tu ...
Veramente su Linux fork non duplica quasi niente. Esiste il copy on write. 
Per contro i thread richiedono l'esistenza di un thread dedicato a 
controllare gli altri. 
In generale non esiste una cosa che sia meglio dell'altra in generale, 
entrambi gli approcci hanno vantaggi e svantaggi.
Ciao
-- 
As.| Simone Piccardi - KeyID:2A972F9D - 
JabberID:sim...@jabber.linux.it
 
So.| 
http://firenze.linux.it/~piccardi
  -  
http://www.softwarelibero.it
 
Li.| Prima ti ignorano, poi ti deridono, poi ti combattono.  Poi vinci. 
                                                           M. K. Ghandi

 decisamente banale.
Dipende dal meccanismo che ti serve. Le pipe sono veloci e relativamente 
semplici da usare, se fanno al caso tuo.  Certo che usare SysV e` 
complicato (e quell'interfaccia e` una schifezza). Purtroppo il supporto ai 
semafori POSIX non e` ancora implementato.
Anche nei thread devi prevedere dei meccanismi di sincronizzazione e di 
controllo di accesso alla memoria condivisa (che essendo tutta condivisa di 
default puo` essere piu` facile da danneggiare).


  Ciao
ciao ...


 tutto a prescindere ..
Virtualmente viene  tutto duplicato. Per  questioni di  efficienza linux
usa  un approccio  COW:  appena dopo  la fork()  i  due programmi  hanno
diversi address space le cui pagine virtuali, pero`, puntano alle stesse
pagine fisiche. Appena uno  dei due programmi effettua  una scrittura in
memoria (i.e.  modifica un  variabile) questo  riceve una  copia privata
della pagina  interessata (la pagina  fisica viene copiata in  un pagina
libera  che  viene  poi  assegnata  al processo  che  ha  effettuato  la
scrittura).
Quanto  al  discoro  threads  vs.  fork(),  i  thread  risultano  ancora
abbastanza pesanti  nei kernel 2.4  (soprattutto in fase di  creazione e
distruzione), mentre nei  2.5 la situazione e`  radicalmente cambiata (a
favore dei threads).
Trovi  un  spiegazione  piu`  dettagliata  della fork()  e  del  COW  su
qualunque testo che tratti di  sistemi operativi. Se vuoi posso mandarti
i post che sono passatti sulla lkml relativi ai threads nei kernel 2.5.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
La differenza fra l'intelligenza e la stupidita`?
All'intelligenza c'e` un limite.

 semplice.
Probabilmente.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! Asynchronous inputs are at the root of our race problems. !>-
                 D. Winker and F. Prosser

 semplici da usare, se fanno al caso tuo.  Certo che usare SysV e` [cut]
Quindi per lo scambio dati userò le pipe... devo inviare i dati solamente
dai miei thread (o processi, ehhe, devo ancora decidere) verso il programma
principale... ad una velocità abbastanza alta... o c'e' altro di più veloce?


wrote:

Se usi i thread è inutile usare le pipe: si nello stesso spazio di
indirizzamento.
La memoria condivisa è la IPC più veloce.
F.

  Kronos
ciao ... grazie ancora per la spiegazione ...


 La memoria condivisa è la IPC più veloce.
Un problema che mi sono sempre posto riguarda la gestione della memoria
condivisa. Una volta allocata la pagina, sarebbe comodo poter
gestirne l'allocazione/deallocazione di un pool tramite funzioni tipo
malloc/free. In modo, ad esempio, di condividere strutture un po' piu'
complesse, quali alberi, grafi e simili. Esistono librerie/funzioni a
riguardo, o si deve creare un set di funzioni ad hoc?


riguardo, o si deve creare un set di funzioni ad hoc?
Adesso non ricordo bene, ma se venisse gestita la riallocazione,
allora potrebbe anche darsi che i dati presenti vengano corrotti.
man ipc  x saperne di più .
(scusa, ma la shm l'ho usata l'ultima volta 4 anni fa e non ho una
macchina UNIX sotto adesso...)
Cmq  viene allocata un'area di memoria condiivsibile tra + processi,
ma non è strutturata. Dovresti gestirti tutto da te.
Se devi utilizzare strutture dati dinamiche ti conviene lavorare con i
thread. Eviti un mucchio di rogne.
Ciao
F.

 non sai se anche FreeBSD ha questi "problemi" con i pthreads ??
Non lo so...
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Mi piace avere amici rispettabili;
Mi piace essere il peggiore della compagnia.

 i post che sono passatti sulla lkml relativi ai threads nei kernel 2.5.
Interesserebbero anche a me. Magari potresti fare un followup qui.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.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

 riguardo, o si deve creare un set di funzioni ad hoc?
be, usando il C++, basta definire una f. my_new_handler() per allocare 
memoria condivisa o morire nel tentativo, set_new_handler(my_new_handler),
fare le due versioni di delete necessarie, e ci sei: ogni chiamata a new e
delete succesiva a queste operazioni, agira' nella mem. condivisa
vedi per info i cap. 3.7.3.2 e 18.4.1 dello standard, o anche di un draft
recente
-- 
#include <stdio.h>/* (C) BW2K+2 This code is released under GPL 2+ */
int main(){char c[]={98,108,97,99,107,119,111,108,102,64,100,101,115,112,
97,109,109,101,100,46,99,111,109,32,119,101,98,46,116,105,115,99,97,108,
105,46,105,116,47,98,108,97,107,119,111,108,102,0};printf("%s\n",c);}

 thread. Eviti un mucchio di rogne.
Infatti, e' stata la mia conclusione...


 operazioni, agira' nella mem. condivisa
mmmh... aspetta, intendi dire che la gestione del pool la devo comunque
riscrivere io? :( vabbe'.
Ma possibile che non esistano librerie a riguardo? di solito, come
vengono gestite queste esigenze di condivisione della memoria?
HappyCactus sospirante



Io userei i processi, il demone lancia i processi figli con il compito di
gestire i modem e comunica attraverso pipe.
L'uso dei thread temo ti possa complicare inutilmente la vita sia come
programmazione che come debug, hai meno problemi di portabilita' e per
controllare dei modem gsm non e' che ti serva tutta quella gran velocita'.
Inoltre se un processo figlio impazzisce e' piu' semplice killarlo ed il
processo padre lo rimpiazzera' senza grossi problemi.
Spero che la mia ignoranza sui thread non mi faccia fare brutta figura.
Alessandro.

 vengono gestite queste esigenze di condivisione della memoria?
provato con google?
comunque, dipende dal contesto e dal tipo di dati in memoria:
- se tutto gira sulla stessa macchina, puoi usare le pipe, la shm, o
  quant'altro
- per portabilita' tra server con OS e architetture diversi, di solito 
  conviene usare socket TCP o similari, o addirittura nel caso di dati 
  grezzi, un dump testuale e' la cosa migliore: immagina gestire 
  endianess, rappresentazione dei float, etc etc. 
- se poi i dati devono essere accceduti da + parti, in vari modi, con 
  ricerche etc etc, allora ti serve un DBMS
oddio, ho appena detto che un dbms e' un meccanismo di interprocess 
communication... o sono pazzo o sono un genio
come? non sono un genio?



first NPT vs. NGPT vs. LinuxThreads benchmark results
"The results of this test series are:
- - LinuxThreads indeed had several problems
- - NGPT indeed run much faster (twice the performance)
- - NPTL runs four times faster than NGPT in a benchmark which by all
   means should favor an M-on-N implementation."
C'e` una montagna di materiale, con una ricerca per autore (Ingo Molnar)
e qualche filtro  dovresti riuscire ad estrarre dalla  lkml tutto quello
che vuoi sapere.
ciao
Kronos
PS: i Message-ID sono relative alle mail passate sulla lkml, non ad
articoli su usenet.
-- 
Home: 
http://kronoz.cjb.net
"New processes are created by other processes, just like new
 humans. New humans are created by other humans, of course,
 not by processes." -- Unix System Administration Handbook

 communication... 
In senso lato, molto lato, hai ragione... Ma anche un server http, a sto
punto...



Ma se usi i thread sono sufficienti la malloc e la free standard, dato che
lo spazio di indirizzamento e' gia' comune.

 che lo spazio di indirizzamento e' gia' comune.
claro que si.
Si parlava di shm e system-V ipc 


 sto punto...
 
umm, no. il server http non permette la modifica dei files. l'odbms si


 umm, no. il server http non permette la modifica dei files. l'odbms si
pensavo al metodo post e al php... :) vabbe', fa niente, una tara
mentale mia :)


 mentale mia :)
Beh, c'e` anche il metodo PUT e, volendo farsi male, le estensioni
FrontPage... :)
Bye.