Come testare e confrontare le implementazioni di mutex

Come dice il titolo: Come testare e confrontare correttamente diverse implementazioni di mutex in c ++?

In sostanza, ho scritto la mia classe simile a std :: mutex per un progetto in esecuzione su un 2 core, armv7 con l'obiettivo di ridurre al minimo l'overhead nel caso non contestato. Ora sto pensando di usare detto mutex in più luoghi e anche in architetture diverse, ma prima di farlo vorrei accertarmene

• è effettivamente corretto
• non ci sono casi patologici in cui si comporta molto peggio di uno standard std :: mutex.

Ovviamente, ho scritto alcuni unit test di base e micro-benchmark e tutto sembra funzionare, ma nel codice multi-thread "sembra funzionare" non mi dà molto conforto.

• Quindi, ci sono tecniche di analisi statiche o dinamiche stabilite?
• Quali sono le insidie ​​comuni quando si scrivono unit test per le classi mutex?
• Quali sono i casi limite tipici che dovresti cercare (dal punto di vista delle prestazioni)?

Sto solo usando tipi di libreria standard per l'implementazione, che include operazioni di caricamento e memorizzazione non sequenziali su atomica. Tuttavia, sono principalmente interessato alla consulenza agnostica di implementazione, poiché mi piacerebbe utilizzare lo stesso cablaggio di test anche per altre implementazioni.

Il problema è complesso:

Alcune fonti di complessità includono:

• Quanti switch di contesto sono in corso: questo è molto importante a seconda della piattaforma su cui vengono eseguiti questi test. Alcune piattaforme lo gestiscono meglio di altre
• Sono le funzioni in cui i mutex sono testati in linea o no. cioè il mutex funziona bene solo con un codice ben ottimizzato o ottimizzabile.
• Questi mutex sono progettati per la localizzazione della cache. Gli errori nella cache riducono significativamente le prestazioni o causano più cambi di contesto. prima e dopo l'inserimento del mutex.
• Il mutex stesso causerà la perdita della localizzazione della cache. cioè i dati sullo stato mutex sono allocati dinamicamente.
• Questi mutex funzioneranno bene laddove all'interno del mutex sono presenti gli switch di contesto. cioè io, malloc ecc.
• Il mutex funzionerà bene se il tempo del kernel è contenuto nell'allocazione e nella dislocazione dinamica della memoria mutex.ie.
• Le prestazioni sono valide quando si esegue all'interno di VM
• La distruzione o la costruzione del mutex sono costose, ovvero i dati sullo stato si trovano nella memoria dinamica

La tua idea è molto interessante: un benchmark di conformità rispetto al quale è possibile testare un'implementazione di mutex.

Sfortunatamente, per quanto ho potuto vedere, non esiste un benchmark di conformità ampiamente noto per le implementazioni di mutex. Quindi, immagino che tu abbia tra le mani il problema molto interessante di creare una proposta per tale benchmark di conformità.

E, dal momento che sei stato coinvolto nella creazione di un'implementazione di benchmark, sei il ragazzo.

Se mi permetti un suggerimento, forse potresti iniziare questa ricerca con lo standard POSIX per i thread su un lato e alcuni studi sulla letteratura teorica dell'elaborazione simultanea, come CSP o Communicating Sequential Processes. Questo tipo di articoli di solito affronta i classici problemi contemporanei, come i filosofi da pranzo.

Una loro implementazione potrebbe essere una parte interessante del tuo benchmark di conformità, immagino.