-
race conditionsScritto daNon Autenticatoil 2010-11-17 13:37:00.0 alle 2010-11-17 13:37:00.0M'è venuta la curiosità di sapere come fanno i filesystem a evitarle, dato che operazioni quali lo spostamento e la cancellazione comportano lo scrivere qualcosa dentro la tabella di allocazione di file e directory, che è un file.
-
Re: race conditions
- Scritto da:
> M'è venuta la curiosità di sapere come fanno i
> filesystem a evitarle, dato che operazioni quali
> lo spostamento e la cancellazione comportano lo
> scrivere qualcosa dentro la tabella di
> allocazione di file e directory, che è un
> file.
Strettamente parlando, no.`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: race conditionsScritto daNon Autenticatoil 2010-11-17 14:17:00.0 alle 2010-11-17 14:17:00.0> > M'è venuta la curiosità di sapere come fanno i
> > filesystem a evitarle, dato che operazioni quali
> > lo spostamento e la cancellazione comportano lo
> > scrivere qualcosa dentro la tabella di
> > allocazione di file e directory, che è un
> > file.
>
> Strettamente parlando, no.
Ma in senso lato è comunque un insieme di blocchi che contiene delle informazioni. Quali misure si adottano per impedirne l'accesso simultaneo in scrittura a diversi processi o istanze di processi?-
Re: race conditions
- Scritto da:
> > Strettamente parlando, no.
>
> Ma in senso lato è comunque un insieme di blocchi
> che contiene delle informazioni. Quali misure si
> adottano per impedirne l'accesso simultaneo in
> scrittura a diversi processi o istanze di
> processi?
Un kernel lock che assicura l'accesso atomico agli inode
?
`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: race conditionsScritto daNon Autenticatoil 2010-11-17 15:12:00.0 alle 2010-11-17 15:12:00.0> > > Strettamente parlando, no.
> >
> > Ma in senso lato è comunque un insieme di
> blocchi
> > che contiene delle informazioni. Quali misure si
> > adottano per impedirne l'accesso simultaneo in
> > scrittura a diversi processi o istanze di
> > processi?
>
> Un kernel lock che assicura l'accesso atomico
> agli inode
> ?
Ma se a certe operazioni corrispondono cambiamenti nella tabella d'allocazione, bisognerà anche disciplinare l'accesso a questa tabella, no?
La domanda mi è venuta pensando al fatto che un archivio zip contiene un filesystem. Poi mi sono detto che però un vero filesystem è meglio perché prevede qualcosa contro le race condition, poi mi son chiesto cosa.-
Re: race conditions
- Scritto da:
> > Un kernel lock che assicura l'accesso atomico
> > agli inode
> > ?
>
> Ma se a certe operazioni corrispondono
> cambiamenti nella tabella d'allocazione,
> bisognerà anche disciplinare l'accesso a questa
> tabella,
> no?
Appunto, l'accesso avviene in maniera "seriale", ogni syscall che accede alla tabella degli inode viene eseguita senza essere interrotta da un'altra.
Oh, la butto li', magari l'accesso concorrente e' piu' "fine granuliert" (Non so come si dice in italiano) e il lock non e' a livello di tabella degli inode bensi' a livello di inode stesso (?).
E' passato tanto tempo da quando ho divorato "Bach, Maurice (1986), The Design of the UNIX Operating System, Prentice Hall, ISBN 0-13-201799-7" ...
`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: race conditionsScritto daNon Autenticatoil 2010-11-17 15:33:00.0 alle 2010-11-17 15:33:00.0> > > Un kernel lock che assicura l'accesso atomico
> > > agli inode
> > > ?
> >
> > Ma se a certe operazioni corrispondono
> > cambiamenti nella tabella d'allocazione,
> > bisognerà anche disciplinare l'accesso a questa
> > tabella,
> > no?
>
> Appunto, l'accesso avviene in maniera "seriale",
> ogni syscall che accede alla tabella degli inode
> viene eseguita senza essere interrotta da
> un'altra.
> Oh, la butto li', magari l'accesso concorrente e'
> piu' "fine granuliert" (Non so come si dice in
> italiano)
Dall'inglese "fine grained", in italiano non avrei idea di come esprimere questo concetto (letteralmente "a grana fine" ma non credo si usi in questo senso). Tra un po' tutte le altre lingue saranno dialetti dell'inglese.
> e il lock non e' a livello di tabella
> degli inode bensi' a livello di inode stesso
> (?).
Sembrerebbe più sicuro.
> E' passato tanto tempo da quando ho divorato
> "Bach, Maurice (1986), The Design of the UNIX
> Operating System, Prentice Hall, ISBN
> 0-13-201799-7"
> ...
Questa è roba a bassissimo livello: devo chiedere ad alex.tg come fa o prevede di fare il suo microkernel.-
Re: race conditions- Scritto da:
> > e il lock non e' a livello di tabella
> > degli inode bensi' a livello di inode stesso
> > (?).
>
> Sembrerebbe più sicuro.
Sopratutto piu' performante.
> > E' passato tanto tempo da quando ho divorato
> > "Bach, Maurice (1986), The Design of the UNIX
> > Operating System, Prentice Hall, ISBN
> > 0-13-201799-7"
> > ...
>
> Questa è roba a bassissimo livello:
Trovato questo: http://books.google.ch/books?id=cbbMrRNiC4cC&pg=PT...
Sezione "Inode semaphore"`"la realta' non e' cosi' terrificante come vogliono farti credere" - Giambo ` - Wakko che cita Giambo-
Re: race conditionsScritto daNon Autenticatoil 2010-11-17 16:00:00.0 alle 2010-11-17 16:00:00.0> > Questa è roba a bassissimo livello:
>
> Trovato questo:
> http://books.google.ch/books?id=cbbMrRNiC4cC&pg=PT
>
> Sezione "Inode semaphore"
Bel libro, spiegazioni chiare. Peccato che non essendo un informatico, ma solo un semplice curioso, non avrò mai occasione di leggerlo.
-
GRRScritto daNon Autenticatoil 2010-11-17 16:57:00.0 alle 2010-11-17 16:57:00.0> > > Questa è roba a bassissimo livello:
> >
> > Trovato questo:
> >
> http://books.google.ch/books?id=cbbMrRNiC4cC&pg=PT
> >
> > Sezione "Inode semaphore"
>
> Bel libro, spiegazioni chiare. Peccato che non
> essendo un informatico, ma solo un semplice
> curioso, non avrò mai occasione di leggerlo.
>
Anni fa ho scritto un programmone per evitare le race conditions mettendo in coda le istanze concorrenti, che usava la creazione "atomica" di directory come segnale di risorsa occupata. Gestiva anche i deadlock in modo trasparente, senza bloccare nessuno con messaggi tipo "riprova un'altra volta". Nei collaudi è sembrato funzionare.
Poi una discussione con un programmatore, e conseguenti altre prove, mi ha convinto che flock funziona altrettanto bene.
Però non sono ancora del tutto convinto che il mio programma sia completamente superfluo, dato che mette le richieste d'accesso in coda mentre flock si limita a bloccare la risorsa in uso senza specificare quale tra le istanze concorrenti se la accaparra al cessare del blocco. Flock mi sembra una folla che si accalca contro una porta che ogni tanto viene aperta e lascia passare una persona, mentre il mio programma crea una fila disciplinata come gli inglesi alla fermata del pullman.
Ma usare un programmone in certi casi può introdurre delle lentezze inaccettabili, per esempio nel caso di un contatore di accessi a una pagina web. È inaccettabile attendere una pagina perché un altro accesso in corso blocca il contatore: in tal caso è meglio permettere al processo arrivato per primo l'accesso al registro del conto, e dire all'altro di lasciar perdere (e questo flock non credo lo permetta).
Il contatore di insulae.net
(che non ho scritto io) usa flock e per quanto ho guardato sembra usarlo correttamente. Eppure ogni tanto pianta pasticci che potrebbero derivare da race condition (alex.tg diceva che i pasticci si verificano comunque). La cosa mi disturba, non ho tempo per occuparmene perché ho altri pensieri, non ho risorse mentali da allocare per il backstudying, et excrucior.
-
Re: GRR> (alex.tg diceva che i pasticci si
> verificano comunque).
Si`, confermo pasticci con flock ai tempi di Red Hat 7.2 e PHP boh... quattro e qualcosa. Non funzionava bene, mai capito perche`. Ma neanche m'interessa, tanto prima o poi buttero` tutto nel cesso delle cose che non ho fatto io.
-
Re: GRRScritto daNon Autenticatoil 2010-11-17 17:52:00.0 alle 2010-11-17 17:52:00.0> > (alex.tg diceva che i pasticci si
> > verificano comunque).
>
> Si`, confermo pasticci con flock ai tempi di Red
> Hat 7.2 e PHP boh... quattro e qualcosa. Non
> funzionava bene, mai capito perche`. Ma neanche
> m'interessa, tanto prima o poi buttero` tutto nel
> cesso delle cose che non ho fatto io.
>
Un cesso gigantesco.
Sono stato or ora sulla pagina della funzione flock() di PHP, e pare abbiano rivoluzionato molto. Hanno anche segato dai commenti diversi messaggi che dicevano che flock() non funziona e la mia risposta (l'utente che compare nei commenti come dranger mi aveva poi spiegato che funziona... se usato correttamente, cosa che molti non sanno fare). Quando riprenderò in mano la questione - per adesso l'università mi assonnolisce - potrò vedere se i cambiamenti occorsi possono essere responsabili del comportamento anomalo del contatore su insulae.net.
-
-
-
-
-
-
-
-
-
-
-