Copy-on-write: differenze tra le versioni

Versione delle 09:44, 16 dic 2019

Versione delle 22:21, 16 mag 2024

Riga 17:

L'implementazione di una strategia copy-on-write impone che, nel sistema, l'identificazione delle risorse interessate sia svincolata ed indipendente (almeno dal punto di vista degli utilizzatori) dalla loro effettiva collocazione fisica; è cioè necessario che tali risorse siano [[virtualizzazione|virtualizzate]].

Ciò che gli utilizzatori conoscono ed usano è un [[identificatore]] di [[Memoria virtuale|risorsa virtuale]], attraverso il quale richiedere al sistema l'accesso alla risorsa; il sistema, per parte sua, associa ciascun identificatore alle informazioni necessarie per poter accedere alla vera e propria [[Memoria fisica|risorsa fisica]]. Nel seguito si indicheranno convenzionalmente:

* con I<submath>XI_X</submath> l'identificatore di una generica risorsa virtuale;

* con la scrittura I<submath>XI_X \rightarrow R</submath> → R l'associazione intercorrente tra l'identificatore I<submath>XI_X</submath> e la risorsa fisica <math>R</math>.

=== Duplicazione della risorsa virtuale ===

Riga 25:

Nella situazione normale, ogni risorsa fisica è associata ad un unico identificatore:

* <math>I_A \rightarrow R_1</math>

* I_A → R₁

Quando il sistema riceve la richiesta di duplicare la risorsa virtuale I<submath>AI_A</submath>, viene generata una nuova risorsa virtuale I<submath>BI_B</submath> ma non viene creata alcuna nuova risorsa fisica: il nuovo identificatore viene anch'esso associato alla risorsa fisica R<submath>1R_1</submath>:

*<math>I_A \rightarrow R_1</math>

*I_A → R₁

*<math>I_B \rightarrow R_1</math>

*'''I_B''' → R₁

La risorsa fisica R<submath>1R_1</submath> non viene ancora duplicata: a partire da questo momento essa diventa la rappresentazione concreta, uguale ed indistinguibile, di entrambe le risorse virtuali, e attraverso di essa il sistema gestisce tutti gli accessi in lettura effettuati tramite gli identificatori I<submath>AI_A</submath> e I<submath>BI_B</submath>.

Per una corretta gestione del copy-on-write il sistema deve tenere traccia del fatto che I<submath>AI_A</submath> e I<submath>BI_B</submath> non stanno realmente ''condividendo'' la risorsa fisica R<submath>1R_1</submath>, e che pertanto un eventuale tentativo di accedere in scrittura alla risorsa tramite uno qualsiasi di essi deve essere intercettato e opportunamente gestito in modo da non ripercuotersi sugli altri.<ref>Diverso il caso di reale condivisione della risorsa, in cui è invece normale e previsto che qualsiasi modifica effettuata tramite un qualsiasi identificatore ad essa associata risulti visibile anche attraverso tutti gli altri.</ref>

=== Scrittura di una risorsa virtuale ===

Ipotizzando che si renda necessaria un'operazione di scrittura (ad esempio sulla risorsa virtuale I<submath>AI_A</submath>), il sistema constata che tale identificatore si riferisce ad una risorsa fisica condivisa in regime di ''copy-on-write'' e conseguentemente:

* intercetta e sospende l'operazione di scrittura

* crea una nuova risorsa fisica R<submath>2R_2</submath> come copia di R<submath>1R_1</submath>

* associa l'identificatore I<submath>AI_A</submath> a R<submath>2R_2</submath>

A questo punto il sistema si trova nel seguente stato:

* <math>I_A \rightarrow R_2</math>

* I_A → '''R₂'''

* <math>I_B \rightarrow R_1</math>

* I_B → R₁

L'operazione di scrittura inizialmente sospesa può quindi proseguire, modificando lo stato di R<submath>2R_2</submath> senza interferire con quello di R<submath>1R_1</submath>, che continua ad essere accessibile tramite l'identificatore I<submath>BI_B</submath>.

== Principali applicazioni ==