I container della Standard Template Library non sono thread-safe per scritture concorrenti: due o più thread che leggono e modificano la stessa istanza senza mutex o atomici generano corruzione di memoria.
DATA_RACE_STL
→
Un normale 'std::mutex' non tiene traccia dell'identità del thread proprietario; se una funzione acquisisce il lock e poi invoca una funzione interna che tenta di acquisire lo stesso mutex, si verifica un blocco permanente (deadlock).
DEADLOCK_STD_MUTEX
→
Quando due thread modificano frequentemente variabili atomiche distinte ma collocate vicine nella stessa riga di cache della CPU (64 byte), i core invalidano continuamente la cache reciproca; si risolve allineando con 'alignas(std::hardware_destructive_interference_size)'.
FALSE_SHARING_DESTRUCTIVE
→
'std::memory_order_relaxed' garantisce solo l'atomicità della singola variabile ma non impone alcun ordine di sincronizzazione (happens-before) sulle scritture circostanti; per sincronizzare flag di stato con dati protetti è necessario usare 'memory_order_release' e 'memory_order_acquire'.
MEMORY_ORDER_RELAXED_RACE
→
Se il thread produttore invoca 'cv.notify_one()' prima che il thread consumatore abbia acquisito il lock e chiamato 'cv.wait()', la notifica va perduta e il consumatore rimane bloccato per sempre se privo di un flag booleano di stato protetto da mutex.
CV_LOST_WAKEUP_DEADLOCK
→
Nelle implementazioni POSIX e Windows le condition variable possono svegliarsi anche in assenza di chiamate 'notify_one/all'; invocare 'cv.wait(lock)' senza passare un predicato booleano ('cv.wait(lock, []{ return pronto; })') genera race condition logiche.
SPURIOUS_WAKEUP_CV
→
Implementare uno spinlock con 'while (flag.test_and_set()) {}' consuma il 100% di un core della CPU; in C++20 si risolve usando 'flag.wait()' e 'flag.notify_one()' per sospendere il thread sul kernel fino al cambio di stato.
ATOMIC_FLAG_BUSY_SPIN
→
Quando decine di thread acquisiscono continuamente il lock condiviso ('std::shared_lock'), il thread che tenta di acquisire l'accesso esclusivo per scrivere ('std::unique_lock') può rimanere bloccato indefinitamente se l'implementazione del mutex privilegia i lettori.
SHARED_MUTEX_WRITER_STARVATION
→