Qual è la rilevanza pratica degli algoritmi di mutua esclusione da manuale?

C'è stata una buona dose di ricerca sugli algoritmi di mutua esclusione, ad esempio molti di questi sono presentati in libri di testo classici come The Art of Multiprocessor Programming , in cui un intero capitolo è dedicato a loro.

Mi chiedo quali sono le situazioni pratiche in cui si potrebbero aver bisogno di questi algoritmi durante la progettazione di un sistema concorrente, piuttosto che usare primitive di sincronizzazione fornite dal linguaggio e dal sistema operativo tipico (diciamo, fornite dalla libreria pthread)?

Mi vengono in mente molti casi speciali in cui immagino che le primitive standard non siano specificamente calibrate per loro, ad esempio "un lettore frequente e uno scrittore poco frequente", o viceversa, o "esattamente un'operazione di scrittura, molti lettori", ecc. - alcuni degli algoritmi di mutua esclusione da manuale sono significativamente migliori nella pratica in tali situazioni?

Per dirla in breve: quali algoritmi di mutua esclusione sono di rilevanza pratica per un ingegnere che dispone già di una libreria di primitivi di concorrenza tipica del linguaggio?

Risposta: nessuna. Non è di questo che parlano le sezioni di The Art of Multiprocessor Programming di Herlihy e Shavit. Nei capitoli sulla reciproca esclusione, Herlihy e Shavit non ti danno alternative alla pthreadbiblioteca, ti mostrano come implementare l'equivalente della pthreadbiblioteca.

Il capitolo 2 di Herlihy e Shavit è intitolato "Esclusione reciproca". Fornisce una varietà di algoritmi classici per implementare l'equivalente di pthread_mutex_lock()solo con memoria condivisa coerentemente in sequenza. Le mie risposte https://cs.stackexchange.com/a/12632/7459 e https://cs.stackexchange.com/a/30249/7459 discutono dell'importanza di queste implementazioni e ho un puntatore a quello che è pratico per utilizzare su macchine che non hanno operazioni di sincronizzazione hardware integrate. (Articolo di Lamport del 1987 in ACM Trans. On Computer Systems).

Il capitolo 7 di Herlihy e Shavit fornisce una varietà di implementazioni di blocco di spin e code dell'equivalente di pthread_mutex_lock(), e il capitolo 8 si espande per discutere pthread_cond_t(variabili di condizione), pthread_rwlock_t(blocchi lettore / scrittore) e brevemente tocca semaphores. Potrebbero esserci situazioni in cui pthread_rwlock_tpotrebbe essere usato come alternativa pthread_lock_tper motivi di prestazioni (ma di solito no) e in Posix è necessario utilizzare semaphoresper la sincronizzazione tra processi.

I capitoli da 9 a 16 riguardano principalmente le applicazioni (vari tipi di contenitori concorrenti). Il capitolo 17 discute brevemente l'equivalente di pthread_barrier_t.

Detto questo, Herlihy e Shavit sono due dei fautori più vocali della memoria transazionale e una varietà di tipi di sincronizzazione non bloccante (e senza attesa). Queste tecniche sono intese come alternative all'esclusione reciproca in alcuni casi. Herlihy e Shavit spargono varie implementazioni non bloccanti nei Capitoli da 9 a 16, quindi entrano nei dettagli sulla memoria transazionale nel Capitolo 18.

La memoria transazionale e altre tecniche di sincronizzazione non bloccanti hanno lo scopo di affrontare il problema che alcuni algoritmi mal progettati richiedono che i thread mantengano le loro sezioni critiche per un tempo molto lungo. La memoria transazionale e la sincronizzazione veramente non bloccante non sono attualmente alternative pratiche in nessuna situazione reale, ma le tecniche per trasformare strutture di dati bloccanti in strutture di dati non bloccanti sono utili nella pratica per ridurre al minimo il tempo in cui una struttura di dati bloccante rimane nella sua criticità sezione. (Spesso è possibile ridurre le dimensioni della sezione critica fino a un paio di istruzioni della macchina.)