Descrivi il meccanismo specifico attraverso il quale **std::promise** trasferisce gli oggetti di eccezione oltre i confini dei thread all'associato **std::future**, e perché ciò richiede una cancellazione del tipo dell'eccezione all'interno dello stato condiviso?

Risposta alla domanda

Storia della domanda.

La funzionalità std::future e std::promise è arrivata in C++11 per formalizzare il trasferimento asincrono dei risultati tra thread. Approcci precedenti si basavano su memoria condivisa ad-hoc con sincronizzazione manuale, il che rendeva quasi impossibile la gestione delle eccezioni oltre i confini dei thread. Il comitato di standardizzazione richiedeva un meccanismo in grado di catturare qualsiasi tipo di eccezione sollevata in un thread di lavoro e riprodurla fedelmente nel thread in attesa senza conoscere il tipo statico dell'eccezione al momento della memorizzazione.

Il problema.

Gli oggetti di eccezione sono polimorfici e allocati nello stack per impostazione predefinita, ma devono sopravvivere al contesto dello std::promise che li ha prodotti. Poiché std::future è templatizzato solo sul tipo di risultato, non sul tipo di eccezione, lo stato condiviso non può contenere un membro eccezione di tipo. Inoltre, il thread consumatore può sopravvivere al thread produttore, richiedendo che l'eccezione persista in uno storage allocato nell'heap con semantiche di proprietà condivisa.

La soluzione.

Lo standard impone che std::promise utilizzi std::exception_ptr per catturare le eccezioni tramite std::current_exception(), che esegue una cancellazione implicita del tipo copiando l'eccezione nell'heap e memorizzando un handle di tipo cancellato. Lo stato condiviso (un blocco di controllo con conteggio dei riferimenti) mantiene questo std::exception_ptr, consentendo a std::future::get() di rilevare l'eccezione e rilanciarla usando std::rethrow_exception().

std::promise<int> prom;
auto fut = prom.get_future();

std::thread([&prom]{
    try {
        throw std::runtime_error("Lavoro fallito");
    } catch(...) {
        prom.set_exception(std::current_exception());
    }
}).detach();

try {
    int val = fut.get(); // Rilancia runtime_error
} catch(const std::exception& e) {
    // Gestisce l'eccezione trasportata
}

Situazione dalla vita reale

Contesto.

Un framework di calcolo distribuito richiedeva ai thread di lavoro di elaborare compiti di segmentazione delle immagini che potevano fallire a causa di eccezioni GPUOutOfMemory o CorruptInputData. Il thread principale doveva ricevere queste eccezioni specifiche per attivare l'elaborazione di fallback della CPU o la ritrasmissione dei dati.

Descrizione del problema.

I tentativi iniziali utilizzavano std::exception_ptr manualmente ma soffrivano di bug di durata in cui le eccezioni venivano distrutte mentre erano ancora referenziate dalla coda degli errori del thread principale. Gli sviluppatori avevano anche difficoltà a memorizzare tipi di eccezione eterogenei in un singolo contenitore di risultati senza slicing o slicing degli oggetti durante la memorizzazione polimorfica.

Soluzione 1: Code di eccezioni tipizzate.

Il team ha considerato di mantenere code separate per ciascun tipo di eccezione utilizzando i template. Questo forniva sicurezza di tipo ma richiedeva std::any per la cancellazione del tipo nella coda comune, aggiungendo un sovraccarico e complessità significativi. Inoltre, interrompeva la capacità di catturare eccezioni in modo naturale con i blocchi try-catch nel thread consumatore.

Soluzione 2: Contenitore di eccezione virtuale.

Hanno implementato una classe astratta ExceptionBase con classi derivate templatizzate memorizzate in std::unique_ptr<ExceptionBase>. Sebbene questo consentisse una memorizzazione polimorfica, richiedeva una logica di clonazione manuale per mantenere la proprietà condivisa tra i thread e introduceva un sovraccarico di dispatch virtuale durante il rilancio. Il conteggio di riferimento personalizzato era soggetto a errori e difficile da rendere sicuro per le eccezioni.

Soluzione scelta e perché.

Il team ha adottato std::packaged_task con std::future, che utilizza internamente il meccanismo std::promise/std::exception_ptr. Questo ha eliminato il codice di cancellazione del tipo personalizzato perché la libreria standard gestiva automaticamente la cattura dell'eccezione e la durata dello stato condiviso. La scelta è stata guidata dalla necessità di sicurezza delle eccezioni senza manutenzione e dal requisito di supportare schemi di gestione delle eccezioni standard senza classi base personalizzate.

Risultato.

Il sistema ha propagato con successo tipi specifici di eccezioni oltre i confini dei thread senza perdite di memoria, anche durante un ridimensionamento aggressivo del pool di thread. Il thread principale poteva catturare specificamente GPUOutOfMemory mentre faceva riferimento a std::exception per errori sconosciuti, mantenendo una separazione pulita tra la logica di gestione degli errori e la sincronizzazione dei thread.

Cosa spesso mancano i candidati

Domanda: Perché std::current_exception() copia l'oggetto eccezione piuttosto che memorizzare un puntatore all'eccezione esistente?

Risposta.

L'oggetto eccezione in un blocco catch è tipicamente una copia temporanea creata dal runtime durante lo smantellamento dello stack. Memorizzare un puntatore raw creerebbe un riferimento pendente una volta che il blocco catch esce e il frame dello stack viene distrutto. Copiando l'eccezione nell'heap, std::current_exception() garantisce che l'oggetto persista indipendentemente dallo stack del thread che lancia. Questa operazione di copia abilita anche il meccanismo di cancellazione del tipo, consentendo a std::exception_ptr di gestire l'oggetto tramite un eliminatore di tipo cancellato mantenendo la possibilità di rilanciare esattamente il tipo originale successivamente.

Domanda: Come previene std::promise le condizioni di gara tra set_value() e set_exception()?

Risposta.

Lo stato condiviso contiene un flag di stato atomico che tiene traccia di se la promessa è soddisfatta. Quando viene chiamato set_value() o set_exception(), l'implementazione esegue un'operazione atomica di confronto e scambio per passare dallo stato "insoddisfatto" a "pronto". Se lo stato è già pronto, l'operazione lancia std::future_error con promise_already_satisfied. Questa transizione atomica garantisce che il thread consumatore che osserva lo stato pronto veda un valore o un'eccezione completamente costruiti, prevenendo letture o scritture parziali durante l'accesso concorrente da parte del produttore e del consumatore.

Domanda: Perché std::exception_ptr può sopravvivere sia allo std::promise che allo std::future che l'hanno creato?

Risposta.

std::exception_ptr utilizza il conteggio dei riferimenti intrusivo sull'oggetto eccezione stesso, indipendentemente dallo stato condiviso di std::future/std::promise. Questo design consente al codice di gestione delle eccezioni di memorizzare errori in log o gestori di errori a lungo termine dopo che l'operazione asincrona è stata completata e gli oggetti.future/promise associati sono stati distrutti. Il conteggio dei riferimenti garantisce che l'oggetto eccezione venga distrutto solo quando l'ultimo std::exception_ptr che lo referenzia viene distrutto, supportando casi d'uso come la segnalazione ritardata degli errori o l'aggregazione delle eccezioni attraverso più operazioni asincrone.