Copy-on-write: differenze tra le versioni

Versione delle 12:45, 16 mag 2015

Versione attuale delle 22:22, 16 mag 2024

(7 versioni intermedie di 6 utenti non mostrate)

Riga 7:

Immediatamente dopo la duplicazione e per tutto il tempo in cui nessuna delle due risorse viene modificata, esse sono, di fatto, indistinguibili; durante questo lasso di tempo la reale esistenza di due copie indipendenti non è strettamente necessaria: il sistema può limitarsi a ''simulare'' l'operazione di duplicazione, mantenendo l'esistenza di un'unica copia e gestendo attraverso di essa, in modo del tutto trasparente ai richiedenti, tutte le operazioni di lettura destinate ad una qualsiasi delle due.

La vera e propria duplicazione della risorsa può essere posticipata fino al momento in cui l'esistenza di due risorse indipendenti non si rende realmente necessaria, ovverocioè in corrispondenza di un'operazione di modifica dello stato (generalmente la scrittura di un nuovo contenuto, da cui il nome di ''copy-on-write'') di una qualsiasi delle copie ''fittizie''.

Il vantaggio principale della strategia copy-on-write risiede nel fatto che se una risorsa duplicata viene successivamente liberata o distrutta senza che nel frattempo né l'originale né la copia siano mai stati modificati, il sistema ha effettivamente evitato una duplicazione non necessaria, con conseguente risparmio di tempo. Il copy-on-write è quindi tanto più vantaggioso quanto più onerosa è l'operazione di duplicazione e quanto più infrequenti sono le operazioni di scrittura.

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 intercettataintercettato e opportunamente gestitagestito 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 ==

La tecnica del ''copy-on-write'' è spesso utilizzata dai [[sistema operativo|sistemi operativi]] per la gestione delle [[protezione della memoria|pagine di memoria]] in regime di [[memoria virtuale]]: le pagine condivise possono essere marcate come di sola lettura in modo tale che gli accessi in scrittura vengano intercettati dalla [[Memoryunità managementdi unitgestione della memoria|MMU]] del processore, che solleva un'[[eccezione (informatica)#Eccezioni hardware|eccezione]] e passa il controllo ad un'apposita funzione di gestione del [[kernel]] che provvede alla duplicazione fisica della pagina interessata prima che la scrittura venga ripresa ed eseguita.

Il ''copy-on-write'' può ad esempio essere sfruttato quando un [[processo (informatica)|processo]] richiede (attraverso la [[chiamata di sistema]] ''[[fork (programmazione)|fork]]'' o analoga) la creazione di un nuovo [[processo figlio]], inizialmente identico a sé stesso,<ref>Il vantaggio di tale approccio è particolarmente evidente nei sistemi in cui il caricamento in memoria di un nuovo programma è scomposto nelle due operazioni di <ttkbd>[[fork (programmazione)|fork]]</ttkbd> ed <ttkbd>[[exec(2)|exec]]</ttkbd>: il [[processo figlio]] originante dalla <ttkbd>fork</ttkbd> non necessita davvero della copia dei dati del processo originale, giacché la successiva chiamata ad <ttkbd>exec</ttkbd> li sostituirà quasi immediatamente con quelli del nuovo programma.</ref> oppure per ottimizzare la creazione di [[buffer]] di grandi dimensioni, in particolare se [[sparsità|sparsi]].<ref>Grandi [[buffer]] [[inizializzazione|inizializzati]] a zero, quali quelli prodotti dalla funzione <ttkbd>[[calloc]]</ttkbd> in [[C (linguaggio)|C]], possono essere ''simulati'' dal sistema facendo puntare tutte le pagine virtuali di memoria necessarie a contenerlo verso un'unica pagina fisica contenente soli byte nulli; solo in seguito, se e quando l'applicazione tenterà di scrivere in tale buffer, il sistema provvederà ad [[Allocazione della memoria|allocare]] fisicamente le pagine di memoria strettamente necessarie.</ref>

== Note ==

Riga 77:

| pagine = 225-278

| anno = 1988

| url = httphttps://www.cis.upenn.edu/~jms/cw-fork.pdf

| lingua = inglese

| accesso = 2009-04-25

}}

{{Portale|informatica}}

[[Categoria:Gestione della memoria]]