Chi ha bisogno della linearizzabilità?

Ho letto delle differenze tra serializzabilità e linearizzabilità , che sono entrambi criteri di coerenza per sistemi replicati come database replicati. Tuttavia, non so in quali casi sarebbe necessaria la linearizzabilità, anche se è più forte della serializzabilità.

Potresti creare scenari in cui una proprietà così forte sarebbe effettivamente necessaria?

Considerare la progettazione di strutture dati simultanee, senza attesa (o senza blocco, che è più debole). In questo scenario, la linearizzazione è generalmente richiesta, anche se in alcuni casi è possibile migliorare le prestazioni e la scalabilità soddisfacendo una condizione di correttezza più debole. Se un'implementazione che soddisfi una condizione così debole è utile dipende solitamente dall'applicazione. Al contrario, un'implementazione linearizzabile è sempre utilizzabile, perché i progettisti possono vederla come atomica.

Inoltre, la linearizzabilità è una proprietà non bloccante: un'operazione totale (definita per tutti gli stati oggetto) non è mai richiesta per bloccare. Invece, la serializzazione non è una proprietà non bloccante. Pertanto, al fine di aumentare il grado di concorrenza, i progettisti di strutture di dati concorrenti fanno sempre affidamento sulla linearizzabilità.

Ho riletto Herlihy e Wing molte volte negli ultimi 15 anni. È una lettura molto difficile. E questo è un peccato, perché mentre ci sono alcune sottigliezze ai bordi, l'idea di base è in realtà abbastanza ragionevole.

In breve: la linearizzabilità è come la serializzabilità, ma con il requisito aggiuntivo che la serializzazione rispetti ulteriori vincoli di ordinamento tra le transazioni. L'obiettivo è consentire di ragionare rigorosamente su una singola struttura di dati atomici anziché dover ragionare sull'intero sistema in una volta.

Anche la linearità è facile da ottenere: basta associare un mutex all'oggetto che si desidera linearizzare. Ogni transazione su quell'oggetto inizia bloccando il mutex e termina sbloccando il mutex.

Ecco le definizioni che userò:

Un sistema è serializzabile se viene dato un set di transazioni su un set di dati, qualsiasi risultato dell'esecuzione delle transazioni è lo stesso di se le transazioni fossero eseguite in un ordine sequenziale e le operazioni all'interno di ciascuna transazione sono contenute all'interno della loro transazione nell'ordine specificato dal codice della transazione.

La serializzazione non consente la comparsa di interfolli di operazioni tra diverse transazioni e richiede che l'ordinamento delle transazioni scelto soddisfi la causalità (se la transazione A scrive il valore x e la transazione B legge il valore x che A ha scritto, la transazione A deve precedere la transazione B in l'ordine seriale prescelto.) Ma non dice nulla su altri vincoli all'ordinamento delle transazioni (in particolare, non dice nulla sui processi e sull'ordine in cui i processi percepiscono gli eventi).

C'è un'altra idea correlata che aggiunge i vincoli sull'ordine in cui i processi hanno eseguito operazioni (ma non parla di transazioni solo singole operazioni di lettura / scrittura):

Un sistema è sequenzialmente coerente se il risultato di qualsiasi esecuzione è lo stesso di se le operazioni di tutti i processi sono state eseguite in un ordine sequenziale e le operazioni di ogni singolo processo compaiono in questa sequenza nell'ordine specificato dal suo programma. ( Lamport, "Come realizzare un computer multiprocessore che esegue correttamente i programmi multiprocesso", IEEE T Comp 28: 9 (690-691), 1979 ).

Nella definizione di coerenza sequenziale è implicito che accettiamo solo ordini sequenziali in cui per ogni posizione di memoria (oggetto) l'ordine sequenziale delle operazioni indotto obbedisce alla regola secondo cui il valore restituito da ciascuna operazione di lettura alla posizione xdeve essere lo stesso valore che è stato scritto da l'operazione di scrittura immediatamente precedente nella posizione xnell'ordine sequenziale.

La linearità ha le buone intenzioni di (a) combinare la nozione di transazioni (dalla serializzazione) con la nozione che i processi prevedono che le operazioni che emettono vengano completate in ordine (da coerenza sequenziale) e (b) restringendo i criteri di correttezza per parlare di ciascuna oggetto in isolamento, piuttosto che costringervi a ragionare sul sistema nel suo insieme. (Vorrei poter dire che l'implementazione del mio oggetto è corretta anche in un sistema in cui ci sono altri oggetti che non sono linearizzabili.) Credo che Herlihy e Wing possano aver cercato di definire rigorosamente un monitor .

La parte (a) è "facile": un requisito sequenziale simile alla coerenza sarebbe che le transazioni sull'oggetto emesse da ciascun processo compaiano nella sequenza risultante nell'ordine specificato dal programma. Un requisito simile alla serializzazione sarebbe che le transazioni sull'oggetto si escludano a vicenda (possono essere serializzate).

La complessità deriva dall'obiettivo (b) (essere in grado di parlare di ciascun oggetto indipendentemente da tutti gli altri).

In un sistema con più oggetti è possibile che le operazioni sull'oggetto B impongano vincoli sull'ordine in cui crediamo che le operazioni siano state invocate sull'oggetto A. Se stiamo osservando l'intera cronologia del sistema, saremo vincolati a determinati ordini sequenziali, e dovrà rifiutare gli altri. Ma volevamo criteri di correttezza che potremmo usare da soli (ragionamento su cosa succede all'oggetto A senza fare appello alla storia del sistema globale).

Ad esempio: supponiamo che stia provando a discutere della correttezza dell'oggetto A, che è una coda, supponiamo che l'oggetto B sia un percorso di memoria e supponiamo che io abbia le seguenti cronologie di esecuzione: Thread 1: A.enqueue (x), A. dequeue () (restituisce y). Discussione 2: A.enqueue (y), A.dequeue () (restituisce x). Esiste un'interlacciamento di eventi che consentirebbe a questa implementazione della coda di essere corretta? Sì:

Thread 1                           Thread 2
A.enqueue(x)                       ...
...                                A.enqueue(y)
...                                A.dequeue() (returns x)
A.dequeue(y) (returns y)           ...

Ma ora cosa succede se la storia ( incluso l'oggetto B ) è: B inizia con il valore 0. Discussione 1: A.enqueue (x), A.dequeue () (restituisce y), B.write (1). Discussione 2: B.read () (restituisce 1) A.enqueue (y), A.dequeue () (restituisce x).

Thread 1                           Thread 2
A.enqueue(x)                       ...
A.dequeue() (returns y)            ...                       (uh oh!)
B.write(1)                         ...
...                                B.read() (returns 1)
...                                A.enqueue(y)
...                                A.dequeue() (returns x)

Ora vorremmo che la nostra definizione di "correttezza" dicesse che questa storia indica che la nostra implementazione di A è buggy o la nostra implementazione di B è buggy, perché non esiste una serializzazione che "abbia senso" (il thread 2 deve leggere un valore da B che non è stato ancora scritto, oppure il thread 1 deve rimuovere un valore da A che non è stato ancora accodato.) Quindi, mentre la nostra serializzazione originale delle transazioni su A sembrava ragionevole, se la nostra implementazione consente una cronologia come la seconda, quindi è chiaramente errata.

Quindi i vincoli che la linearizzazione aggiunge sono abbastanza ragionevoli (e necessari anche per semplici strutture dati come le code FIFO). Sono cose del tipo: "l'implementazione dovrebbe impedire a dequeue () un valore che non sarà accodato () fino a qualche tempo nel futuro." La linearità è abbastanza facile (e naturale) da raggiungere: basta associare un mutex al tuo oggetto e ogni transazione inizia con il blocco e termina con lo sblocco. Il ragionamento sulla linearizzabilità inizia a diventare complicato quando si tenta di implementare la propria atomicità con tecniche non bloccanti o senza blocco o di attesa anziché semplici mutex.

Se sei interessato ad alcuni suggerimenti sulla letteratura, ho scoperto quanto segue (anche se penso che la discussione sul "tempo reale" sia una delle aringhe rosse che rendono la linearità più difficile di quanto debba essere.) Https: // stackoverflow.com/questions/4179587/difference-between-linearizability-and-serializability

Innanzitutto, la linearizzabilità e la serializzabilità non sono direttamente comparabili. Come mostra la tabella seguente, la differenza principale è che sul lato sinistro tutte le singole operazioni sono atomiche (come avere una java synchronizedattorno a ciascuna operazione. Sul lato destro, l'unità di atomicità è una transazione; un'operazione individuale non è atomica Questo è il motivo per cui la serializzazione è sempre stata parte della letteratura del database, mentre il lato sinistro è stato oggetto della letteratura sulla memoria del processore (l'operazione di lettura / scrittura è atomica). Gli archivi di valori-chiave originali (come dbm e memcached) iniziato sul lato sinistro (get / put è atomico), ma quelli più recenti supportano sempre più le transazioni (come la chiave di Google).

obj. le operazioni sono atomiche | Le transazioni sono atomiche
-------------------------------- + ----------------- ----------------
Linearizzabilità |
Coerenza sequenziale | serializzabilità
Coerenza causale |
Coerenza della cache |

La linearità richiede che un sistema di oggetti in un'impostazione concorrente debba comportarsi in modo identico a un sistema sequenziale che gestisce un'operazione (una coppia richiesta / risposta) alla volta - in un universo parallelo - in modo tale che (a) i client in entrambi gli universi vedi esattamente le stesse risposte (b) l'ordine temporale è preservato (più su questo sotto).

La definizione di serializzazione, come la coerenza sequenziale, richiede solo il primo criterio.

La conservazione dell'ordine temporale significa questo: se A: x.op1 () (A è un client, x è un oggetto e op1 è un'operazione) terminata prima dell'avvio di un'altra operazione B: y.op2 (), quindi nell'universo sequenziale il le richieste vengono gestite nello stesso ordine. Ciò non è necessario in coerenza sequenziale (SC); all'oggetto è consentito accodare la richiesta di un client, rispondere al client, quindi valutarlo in seguito. Inoltre, l'oggetto può gestire una richiesta successiva da un altro client fuori turno, valutandola prima di arrivare al primo.

La mancata conservazione dell'ordine temporale è un problema. Dopo A: x.op1 (), supponi che A abbia sollevato il telefono e lo abbia detto a B, quindi B abbia chiamato x.op2 () chiamata. Non c'è modo per il sistema di conoscere questa catena causale di eventi, dal momento che il secondo passo prevedeva un messaggio non tracciato dal sistema. In molti casi reali, non è irragionevole per A supporre che una volta che x abbia risposto, l'invocazione di B può fare affidamento sullo stato aggiornato. Se l'ordine temporale non è stato preservato, A e B sono sorpresi. Ciò non accadrebbe in un sistema linearizzabile.

La seconda bella proprietà della conservazione dell'ordine temporale è la località e la composizionalità, che un sistema costruito con oggetti linearizzabili è esso stesso linearizzabile. Quindi, invece di avere un archivio valori-chiave monolitico, puoi dividerlo in molte partizioni separate ognuna gestita dal proprio server KV-store; se ciascuno di essi è linearizzabile, l'intero database funziona come un archivio monolitico KV linearizzabile, senza alcuno sforzo aggiuntivo.