Newsgroup: it.comp.os.linux.development
Titolo: Memoria condivisa.

Devo realizzare una specie di database gestito da un processo che forka,
crea dei figli che possono leggervi e dei figli che possono scrivervi.
Generalmente, in casi di memoria condivisa sotto linux, come č meglio
gestire la concorrenza tra i processi?
Io avrei pensato queste possibilitą:
1) File a cui tutti possono accedervi
2) Processo che gestisce le code dei vari processi che vogliono accedervi
(una specie di spooler)
3) Semafori, lock unlock etc...
4) Sincronizzazione mediante messaggi
5) Effettiva memoria condivisa (magari con un monitor)
Vi ringrazio anticipatamente e mi scuso se mantengo il discorso sul
generico.
Giovanni

gestire la concorrenza tra i processi?
Diciamo che in generale le soluzioni sono sempre le solite. Io mi sono
sempre trovato bene con semafori + mutex che sono facili da implementare
senza problemi. Sconsiglierei l'accesso ai file. Puoi usare IPC se non ne
devi mandare troppi per sincronizzare i ps. AFAIK i monitor li trovi solo in
java.
--
  	Giuseppe "Cowo" Corbelli  -->>  Riding on Linux-2.2.16
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! Battles Are Fought By Those With The Courage To Believe !>-
  		Manowar - Courage


Sent via Deja.com
http://www.deja.com/

 java.
Anche il Pascal nella sua scarsezza supportava la struttura monitor.
Vi ringrazio tutti, ma penso di aver trovato nell'uso delle shmget,shmctl,
semget,semctl e compagnia bella un'ottima soluzione.
L'unico fastidio è che tanti possono leggervi contemporaneamente ma solo uno
per volta può scrivere nell'area condivisa (e con nessun lettore presente).
Per evitare il posponimento indefinito dell'operazione di scrittura a causa
di un gran traffico di lettori, avrei pensato ad inserire un ulteriore
semaforo di "priorità" che tenga in coda tutti i nuovi lettori finché i
lettori già presenti nella memoria critica non siano usciti e lo scrittore
non abbia scritto.
Ritengo che per il server concorrente che sto progettando sia la soluzione
più pulita. D'altronde il problema lettori/scrittori è un classico della
concorrenza.
Ciao a tutti,
giovanni

java.
non vorrei dire una vaccata, ma comunque si possono implementare i
monitor tramite i semafori, dato che sono funzionalmente equivalenti..
ciao
Giacomo
-- 
Giacomo Tenaglia -- CdL Informatica @ Universita' di Bologna
-->> 
tena...@cs.unibo.it
 || 
iaco...@libero.it

Pape' Satan, pape' Satan aleppe, comincio' Giuseppe con voce chioccia:
GC> senza problemi. Sconsiglierei l'accesso ai file. Puoi usare IPC se non ne
GC> devi mandare troppi per sincronizzare i ps. AFAIK i monitor li trovi solo in
GC> java.
colgo l'occasione per chiedere se qualcuno mi illumina sul
funzionamento dei monitor... ai suoi tempi un professore
mostruosamente ignorante non riusci' minimamente a spiegarci cosa
fossero.
-- 
addio, e grazie per tutto il pesce

Pape' Satan, pape' Satan aleppe, comincio' Dr. con voce chioccia:
DF> colgo l'occasione per chiedere se qualcuno mi illumina sul
DF> funzionamento dei monitor... ai suoi tempi un professore
DF> mostruosamente ignorante non riusci' minimamente a spiegarci cosa
DF> fossero.
oops, chiedo scusa per l'OT, credevo di essere su un altro ng.
(comunque se qualche anima pia me lo spiega lo stesso, a me non
dispiace ;))


dispiace ;))
..a grandi linee:
le variabili del monitor non sono accessibili dai processi se non
tramite le procedure entry;
un solo processo per volta esegue il codice del monitor;
ci sono variabili di condizione, su cui vengono definite due operazioni:
WAIT e SIGNAL:
un processo fa una WAIT: viene messo in una coda di attesa
un processo fa una SIGNAL: viene riattivato il primo processo che stava
aspettando, il chiamante viene messo nello URGENT STACK finche` il
processo risvegliato non ha rilasciato la mututa esclusione.
chiaramente la politica di signal urgent non e` l'unica, ma il mio prof
mi ha spiegato questa..


monitor tramite i semafori, dato che sono funzionalmente equivalenti..
Indubbiamente. Intendevo "un'implementazione stabile e ben fatta, standard'.
-- 
        Giuseppe "Cowo" Corbelli  -->>  Riding on Linux-2.2.16
	**ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! When you say "I wrote a program that crashed Windows", people just stare
     at you blankly and say "Hey, I got those with the system, *for free*" !>-
                                (By Linus Torvalds)