Come tenere traccia del codice sicuro del thread in una base di codice C ++ Rich Legacy per lo più thread non sicura

Question

Come tenere traccia del codice sicuro del thread in una base di codice C ++ Rich Legacy per lo più thread non sicura

#1 da (4 voti)
#2 da (2 voti)

3

Per basi di codice C ++ di grandi dimensioni, nozioni come Herb Sutter " const significa thread-safe " non sembrano aiutare molto, perché ci può essere una quantità schiacciante di codice nelle funzioni const che stanno modificando lo stato senza sincronizzazione. E anche se il codice legacy non fosse un problema, per una classe come ThreadSafeQueue, non vorrai che la funzione push_back sia const solo perché è threadsafe.

Esiste un metodo per tenere traccia di quali funzioni sono concepite come thread-safe, sfruttando idealmente il compilatore per aiutare a rafforzarlo? C'è un modo per simulare un'introduzione di una nuova parola chiave come "threadsafe" che funziona in modo simile a const (cioè il compilatore darà un errore se una funzione denominata "threadsafe" chiama qualsiasi funzione non contrassegnata come threadsafe)?

Forse la mia migliore scommessa è semplicemente taggare le funzioni con un commento standard, magari usando qualcosa come doxygen? Quindi un tag "thread-safe" speciale in un commento al posto della parola chiave const significherebbe "immutabile o internamente sincronizzato".

Qualcuno ha esperienza con il processo di aggiunta del multithreading a un ampio database legacy che potrebbe condividere ciò che ha funzionato e cosa no?

c++ exceptions legacy multithreading

posta JDiMatteo 18.12.2014 - 02:10

fonte

2 risposte

2

Una tecnica se hai un sacco di codice non sicuro dal thread è lasciare che solo un thread abbia accesso ad esso. Se gli altri thread non toccano, la mancanza di sicurezza è un non-problema. Per fare in modo che funzioni, è possibile comunicare con il resto dell'applicazione tramite code di messaggi: le parti thread-safe possono chiedere alla parte non sicura del thread di eseguire alcune operazioni inviando un messaggio e la parte non sicura del thread può rispondere inviando un messaggio indietro (che la parte thread-safe potrebbe o non potrebbe arrestare in attesa, a seconda di cosa sta realmente accadendo nell'applicazione).

Le code dei messaggi devono essere adeguatamente protette contro l'accesso multi-thread, ovviamente, ma sono piuttosto una piccola porzione di codice e possono avere una semantica di blocco dei libri di testo in modo da poterle fare bene anche senza troppo molti problemi.

Questo è concettualmente simile all'esecuzione del codice in un altro processo e alla comunicazione tramite pipe, eccetto che non sei limitato ad inviare messaggi serializzati su byte e puoi usare invece qualcosa di più strutturato.

Il compilatore non può capire come rendere il codice sicuro da thread da solo. È solo questo software, lo sai? Può darti strumenti per renderlo più facile da fare, meno oneroso, ma non lo fa Capisco davvero cosa dovrebbe fare il codice. Tutto quello che può vedere è esattamente ciò che è scritto, ed è praticamente il massimo in termini di avvocati linguistici. È un'idea di ciò che è giusto non è il tuo.

risposta data 29.12.2014 - 09:59

fonte

Leggi altre domande sui tag c++ exceptions legacy multithreading

Oggetto modello e attributi aggiuntivi Perché nella complessità ciclomatica aggiungiamo 1 per gli operatori in una condizione?

score 4 · Accepted Answer

Un modo per aggiungere il multithreading a un'applicazione precedente è utilizzare più processi e comunicazioni tra processi. Ciò consente di isolare il codice in questione, serializzarne la comunicazione e, se il codice presenta bug, perdite di memoria, ecc., È possibile interrompere il processo e riavviarlo automaticamente. Funziona se il sovraccarico IPC vale la sicurezza extra.

Un'altra opzione è scrivere un'API wrapper che sia thread-safe, ma comunica con una libreria interna non thread-safe, usando tecniche di serializzazione o di accodamento. Fai attenzione alla situazione di stallo.

Non penso che C ++ ti aiuterà a migliorare la sicurezza del thread del codice, semplicemente usando il compilatore. Devi rivedere e potenzialmente riscrivere ogni riga.