Alcune domandine semplici sul C

[Cimmo]

Originariamente inviato da ilsensine
[b]
...sicuro?

Ehm...
ma ++x non preincrementa e x++ postincrementa? Perche' fanno la stessa cosa mettendoci ++x o x++ ?

[ilsensine]

int x1 = 1;
int x2 = 1;
++x1;
x2++;
printf("x1: %d x2: %d\n", x1, x2);

[ilsensine]

int x1 = 1;
int x2 = 1;
int y1;
int y2;
y1 = ++x1;
y2 = x2++;
printf("y1: %d y2: %d\n", y1, y2);

Succo: nella for, utilizzo forse il valore restituito da ++x all'atto dell'incremento? No.

[Cimmo]

Originariamente inviato da ilsensine
[b]

int x1 = 1;
int x2 = 1;
int y1;
int y2;
y1 = ++x1;
y2 = x2++;
printf("y1: %d y2: %d\n", y1, y2);

Succo: nella for, utilizzo forse il valore restituito da ++x all'atto dell'incremento? No.

Ok ma prova questo

int x1=0;
int x2=0;
printf("%d %d",++x1,x2++);

probabilmente il for usa quella regola sempre alla fine del ciclo ed e' un caso speciale, pero' ++x e' diverso da x++!!!

[ilsensine]

printf("%d %d",++x1,x2++);

Stai passando alla printf il risultato di ++x/x++. Nel terzo argomento della for invece esegui una operazione, che può essere qualsiasi, senza preoccuparti di un eventuale risultato.

[ilsensine]

Guarda ad es. che puoi fare nel terzo argomento della for:

int main() {
int x;
char a[64];
for(x=0; x<5; (
  sprintf(a, "%d", x++),
  fclose(fopen(a, "w"))
));
return 0;
}

Come vedi, la for se ne frega altamente di quello che succede lì dentro

[Cimmo]

Una conferma: se io uso l'array di semafori, pero' 2 processi possono chiedere la mutuaesclusione contemporaneamente su 2 semafori diversi, io non posso usare la stessa variaibile di appoggio buf, senno' c'e' conflitto...giusto?

[ilsensine]

Sì la puoi usare, a meno che qualche sem* non la modifichi.
Nota che bloccare due diversi semafori di seguito è un BUG che prima o poi ti porta al deadlock.

[Cimmo]

Originariamente inviato da ilsensine
[b]Sì la puoi usare, a meno che qualche sem* non la modifichi.
Nota che bloccare due diversi semafori di seguito è un BUG che prima o poi ti porta al deadlock.

Gia' perche' ogni figlio si fa una copia delle variabili, quindi quelle che usa non sono in comune.
Perche' e' un bug? Se io ho un array di semafori, dove ad ogni semaforo corrisponde una risorsa differente che deadlock puo' portare?

ciao
Cimmo

[ilsensine]

Perche' e' un bug? Se io ho un array di semafori, dove ad ogni semaforo corrisponde una risorsa differente che deadlock puo' portare?

Caso più semplice: prendi due processi A, B e due semafori 1, 2:

A: lock semaforo 1 (ok)
 B: lock semaforo 2 (ok)
A: lock semaforo 2 (in attesa)
 B: lock semaforo 1 (in attesa)
=> deadlock

Potresti usare la semop per effettuare i DUE lock contemporaneamente in maniera atomica, ma la bomba è sempre innescata - se riesci a tenere solo un lock alla volta è meglio.

[Cimmo]

Si ma ogni processo da me non prende la mutuaesclusione di piu' di 1 semaforo alla volta, per prenderne un secondo deve prima rilasciare la prima risorsa...c'e' qualche controindicazione?

[ilsensine]

Originariamente inviato da Cimmo
[b]Si ma ogni processo da me non prende la mutuaesclusione di piu' di 1 semaforo alla volta, per prenderne un secondo deve prima rilasciare la prima risorsa...c'e' qualche controindicazione?

Allora ok, avevo capito il contrario.

[Cimmo]

Urgente: ma io non posso aprire piu' di un listening socket per processo? Perche' io faccio mettere piu' di un processo in ascolto di connect tcp, ma dopo che il primo si e' messo in ascolto, dal secondo processo in poi la bind mi restituisce: Err: 98 "Address already in use"

Se dovesse essere cosi', io come faccio ad avere una ricezione contemporanea di dati?

[cionci]

Chiaro che la bind non ti permette di stare in ascolto sulla stessa porta...
Ci sono diversi modi...

1)
Sul processo padre :
socket
bind
listen
accept

Appena ricevi una connessione fai la fork...ad a quel punto sul figlio gestisci il socket ricevuto dalla accept...mentre nel padre ritorni sulla accept...

Se non hai problemi di prestazioni (creare un nuovo processo con la fork è molto peso) va benissimo...

2) Produttore-consumatore (prefork)
Fai N fork per i consumatori (N figli)...
I figli restano in attesa su una coda che arrivi una connessione da gestire...
Hai un produttore (processo padre) che sta in attesa di ricevere connessioni sulla accept...
Appena ne riceve una mette il socket nella coda...e ritorna in attesa di una connessione...
Il primo processo figlio che viene sbloccato si prende il socket e gestisce la connessione...

Per gestire la coda devi usare 2 semafori e una mutua esclusione...

N è il numero di figli...
Si inizializza SemA a N, SemB a 0...

Immissione :

Lock(SemA)
Lock(mutex)
immetto in coda
Unlock(mutex)
Unlock(SemB)

Prelievo :

Lock(SemB)
Lock(mutex)
immetto in coda
Unlock(mutex)
Unlock(SemA)

3) thread...anche in Linux ci dovrebbero essere i thread (pthread)
Usandoli puoi benissimo recuperare un bel po' di prestazioni sul primo metodo...

[ilsensine]

creare un nuovo processo con la fork è molto peso

Se la creazione del nuovo processo prevede un execve o simili, è molto meglio usare una vfork.

[cionci]

Originariamente inviato da ilsensine
[b]
Se la creazione del nuovo processo prevede un execve o simili, è molto meglio usare una vfork.

vfork che fa ? Non duplica la memoria del processo padre ?

[ilsensine]

Fork è implementata con fork, vfork è implementata con clone.
Non esiste una definizione rigorosa della vfork; sotto linux evita la copia completa della page table del processo padre, in quanto è studiata appositamente per essere lanciata prima di un exec (che sovrascriverebbe comunque la page table).
Nota che su Linux anche la fork non è molto pesante: viene duplicata la page table tra padre e figlio, ma non le pagine di memoria fisica. Le pagine di memoria vengono duplicate nel momento in cui uno dei due tenta una scrittura. Ciò è molto efficiente e comporta:
- miglior gestione della memoria (le pagine che verranno solo lette non vengono duplicate)
- minor latenza della fork

[Cimmo]

Originariamente inviato da ilsensine
[b]
La memoria sopravvive all'uscita del programma, e se hai provato l'esempio che ho postato sulla shm capirai perchè.
Puoi renderlo "autodistruggente" quando il conteggio degli accessi è 0 usando il comando IPC_RMID con la shmctl (v. man).

Quindi per liberare la memoria al termine del programma mi basta fare cosi':
shmctl(id,IPC_RMID,??);
Come terzo parametro che ci devo mettere?

Anche i semafori rimangono in memoria? O si autoeliminano al termine del programma?

Thanx...

P.S.= Sto facendo un software niente male...

[ilsensine]

Quindi per liberare la memoria al termine del programma mi basta fare cosi':
shmctl(id,IPC_RMID,??);
Come terzo parametro che ci devo mettere?

Non è specificato, ma credo che sia ignorato, quindi dovrebbe poter essere NULL.

Anche i semafori rimangono in memoria? O si autoeliminano al termine del programma?

Come per la shm, possono essere distrutti con la semctl(.., 0, IPC_RMID)
Controlla la pagina man per vedere cosa succede quando rimuovi un set di semafori.

[Cimmo]

Originariamente inviato da ilsensine
[b]
Non è specificato, ma credo che sia ignorato, quindi dovrebbe poter essere NULL.


Come per la shm, possono essere distrutti con la semctl(.., 0, IPC_RMID)
Controlla la pagina man per vedere cosa succede quando rimuovi un set di semafori.

La semctl dice che il secondo parametro viene ignorato, quindi dovrebbe eliminare con un solo comando anche un array di semafori come ho io nel mio caso, giusto?

Altra domanda:
ho usato il metodo strnlen di string.h e in fase di compilazione mi da' questo warning: host.c: In function `main': host.c:436: warning: implicit declaration of function `strnlen'
in teoria non dovrebbe essere un errore che appare quando non includi il file header? Eppure ho incluso un file .h che a sua volta include string.h quindi non capisco perche' non lo trova...