Come testare e confrontare le implementazioni mutex

Question

Come testare e confrontare le implementazioni mutex

#1 da (1 voti)
#2 da (-1 voti)

12

Come dice il titolo: come si testano e si confrontano le diverse implementazioni di mutex in c ++?

Essenzialmente ho scritto la mia classe std :: mutex like per un progetto eseguito su un core 2, armv7 con l'obiettivo di minimizzare il sovraccarico nel caso non contestato. Ora sto considerando l'utilizzo di detto mutex in più punti e anche in diverse architetture, ma prima di farlo vorrei assicurarmi che

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

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

Quindi, esistono tecniche di analisi statiche o dinamiche stabilite?
Quali sono i problemi più comuni durante la scrittura di unit test per le classi mutex?
Quali sono i tipici casi limite che dovrebbero essere considerati (per quanto riguarda le prestazioni)?

Uso solo i tipi di libreria standard per l'implementazione, che include carico & non sequenziale-coerente immagazzinare operazioni su atomics. Tuttavia, sono principalmente interessato alla realizzazione di consigli agnostici, dal momento che mi piacerebbe utilizzare lo stesso cablaggio di test anche per altre implementazioni.

testing c++ mutex

posta MikeMB 18.06.2017 - 15:26

fonte

2 risposte

Leggi altre domande sui tag testing c++ mutex

Esiste un libro di algoritmi che insegna come la serie Head First? [chiuso] I programmatori Python trovano il problema dello spazio bianco inopportuno? [chiuso]

score 1 · Answer 1

Il problema è complesso:

Alcune fonti di complessità includono:

Quanti interruttori di contesto sono in corso: questo è molto importante in base alla piattaforma su cui vengono eseguiti questi test. Alcune piattaforme gestiscono questo meglio di altri
Sono le funzioni che i mutex sono testati in linea o meno. cioè il mutex funziona bene solo in un codice ben ottimizzato o ottimizzato.
Questi mutex sono progettati per la localizzazione della cache. Le carenze nella cache riducono significativamente le prestazioni o causano più switch di contesto. prima e dopo l'inserimento del mutex.
Il mutex stesso causerà la perdita della localizzazione della cache. cioè i dati di stato mutex sono allocati dinamicamente.
Questi mutex funzioneranno bene quando gli switch di contesto sono contenuti nel mutex. io, io, malloc ecc.
Il mutex funzionerà bene se il tempo del kernel è contenuto nel mutex.i.e. allocazione e dealazione dinamica della memoria.
Le prestazioni vengono mantenute durante l'esecuzione in VM
La distruzione o la costruzione del mutex costoso, ovvero i dati di stato, si trovano nella memoria dinamica

score -1 · Answer 2

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

Sfortunatamente, per quanto ho potuto vedere, non esiste un benchmark di conformità ampiamente noto per le implementazioni mutex. Quindi, immagino tu abbia tra le mani il problema molto interessante di creare una proposta per tale parametro 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 sui processi sequenziali comunicanti. Questo tipo di carte di solito tratta i classici problemi simultanei, come i Philosophers di sala.

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