Perché non riesco a verificare se un mutex è bloccato?

C ++ 14 sembra aver omesso un meccanismo per verificare se un std::mutex è bloccato o meno. Vedi questa domanda SO:

/programming/21892934/how-to-assert-if-a-stdmutex-is-locked

Ci sono molti modi per aggirare questo, ad esempio usando;

std::mutex::try_lock()
std::unique_lock::owns_lock()

Ma nessuna di queste sono soluzioni particolarmente soddisfacenti.

try_lock()è autorizzato a restituire un falso negativo e ha un comportamento indefinito se il thread corrente ha bloccato il mutex. Ha anche effetti collaterali. owns_lock()richiede la costruzione di un unique_locksopra l'originale std::mutex.

Ovviamente potrei farlo da solo, ma preferirei capire le motivazioni per l'interfaccia attuale.

La capacità di controllare lo stato di un mutex (ad es. std::mutex::is_locked()) Non mi sembra una richiesta esoterica, quindi sospetto che il Comitato Standard abbia deliberatamente omesso questa funzionalità piuttosto che essere una svista.

Perché?

Modifica: Ok, quindi forse questo caso d'uso non è così comune come mi aspettavo, quindi illustrerò il mio scenario particolare. Ho un algoritmo di apprendimento automatico che è distribuito su più thread. Ogni thread funziona in modo asincrono e torna a un pool principale dopo aver completato un problema di ottimizzazione.

Quindi blocca un mutex master. Il thread deve quindi scegliere un nuovo genitore da cui mutare una prole, ma può scegliere solo da genitori che attualmente non hanno una prole ottimizzata da altri thread. Devo quindi eseguire una ricerca per trovare genitori che non sono attualmente bloccati da un altro thread. Non vi è alcun rischio che lo stato del mutex cambi durante la ricerca, poiché il thread principale mutex è bloccato. Ovviamente ci sono altre soluzioni (attualmente sto usando un flag booleano) ma ho pensato che il mutex offre una soluzione logica a questo problema, poiché esiste ai fini della sincronizzazione tra thread.

Riesco a vedere almeno due gravi problemi con l'operazione suggerita.

Il primo è già stato menzionato in un commento di @ gnasher729 :

Non puoi davvero ragionevolmente verificare se un mutex è bloccato, perché un nanosecondo dopo il controllo può essere sbloccato o bloccato. Quindi, se hai scritto if (mutex_is_locked ()) …, allora mutex_is_lockedpotrebbe tornare il risultato corretto, ma per il momento la ifsi esegue, è sbagliato.

L'unico modo per essere sicuri che la proprietà "è attualmente bloccata" di un mutex non cambi è, bene, bloccarlo da soli.

Il secondo problema che vedo è che, a meno che non si blocchi un mutex, il thread non si sincronizza con il thread che aveva precedentemente bloccato il mutex. Pertanto, non è nemmeno ben definito parlare di "prima" e "dopo" e se il mutex è bloccato o meno è una specie di domanda se il gatto di Schrödiger è attualmente vivo senza tentare di aprire la scatola.

Se ho capito bene, entrambi i problemi sarebbero discutibili nel tuo caso particolare grazie al blocco del master mutex. Ma questo non mi sembra un caso particolarmente comune, quindi penso che il comitato abbia fatto la cosa giusta non aggiungendo una funzione che potrebbe essere in qualche modo utile in scenari molto speciali e causare danni in tutti gli altri. (Nello spirito di: "Rendi le interfacce facili da usare correttamente e difficili da usare in modo errato.")

E se posso dire, penso che l'installazione che hai attualmente non sia la più elegante e potrebbe essere riformulata per evitare del tutto il problema. Ad esempio, invece del thread principale che controlla tutti i potenziali genitori per uno che non è attualmente bloccato, perché non mantenere una coda di genitori pronti? Se un thread vuole ottimizzarne un altro, fa uscire quello successivo dalla coda e non appena ha nuovi genitori, li aggiunge alla coda. In questo modo, non è nemmeno necessario il thread principale come coordinatore.

Sembra che tu stia utilizzando i mutex secondari non per bloccare l'accesso a un problema di ottimizzazione, ma per determinare se un problema di ottimizzazione è stato ottimizzato in questo momento o meno.

Questo è completamente inutile. Avrei un elenco di problemi che devono essere ottimizzati, un elenco di problemi da ottimizzare in questo momento e un elenco di problemi che sono stati ottimizzati. (Non prendere letteralmente "elenco", significa "qualsiasi struttura di dati appropriata".

Le operazioni di aggiunta di un nuovo problema all'elenco di problemi non ottimizzati, o di spostamento di un problema da un elenco all'altro, verrebbero eseguite sotto la protezione del singolo mutex "master".

Come altri hanno detto, non c'è nessun caso d'uso in cui is_lockedun mutex sia di alcun beneficio, ecco perché la funzione non esiste.

Il caso con cui stai riscontrando un problema è incredibilmente comune, è fondamentalmente ciò che fanno i thread di lavoro, che sono una delle, se non la più comune, implementazione di thread.

Hai uno scaffale con 10 scatole su di esso. Hai 4 lavoratori che lavorano con queste scatole. Come ti assicuri che i 4 lavoratori lavorino su scatole diverse? Il primo lavoratore prende una scatola dallo scaffale prima di iniziare a lavorarci. Il secondo lavoratore vede 9 scatole sullo scaffale.

Non ci sono mutex per bloccare le scatole, quindi vedere lo stato del mutex immaginario sulla scatola non è necessario e abusare di un mutex come booleano è semplicemente sbagliato. Il mutex blocca lo scaffale.

Oltre ai due motivi indicati nella risposta 5gon12eder sopra, vorrei aggiungere che non è né necessario né desiderabile.

Se stai già tenendo un mutex, allora farai meglio a sapere che lo stai trattenendo! Non è necessario chiedere. Proprio come se possiedi un blocco di memoria o qualsiasi altra risorsa, dovresti sapere esattamente se lo possiedi e quando è appropriato rilasciare / eliminare la risorsa.
In caso contrario, il programma è stato progettato in modo errato e si stanno verificando problemi.

Se è necessario accedere alla risorsa condivisa protetta dal mutex e non si è già in possesso del mutex, è necessario acquisire il mutex. Non c'è altra opzione, altrimenti la logica del programma non è corretta.
È possibile che il blocco sia accettabile o inaccettabile, in entrambi i casi lock()o try_lock()darà il comportamento desiderato. Tutto quello che devi sapere, positivamente e senza dubbio, è se hai acquisito con successo il mutex (il valore di ritorno di try_lockti dice). Non ha importanza se qualcun altro lo detiene o se hai un fallimento spurio.

In tutti gli altri casi, senza mezzi termini, non sono affari tuoi. Non hai bisogno di sapere, e non dovresti sapere, o fare ipotesi (per i problemi di tempestività e sincronizzazione menzionati nell'altra domanda).

È possibile che si desideri utilizzare atomic_flag con l'ordine di memoria predefinito. Non ha gare di dati e non genera mai eccezioni come fa mutex con più chiamate di sblocco (e si interrompe in modo incontrollabile, potrei aggiungere ...). In alternativa, esiste atomico (ad esempio atomico [bool] o atomico [int] (con parentesi triangolari, non [])), che ha funzioni piacevoli come load e compare_exchange_strong.

Voglio aggiungere un caso d'uso per questo: consentirebbe a una funzione interna di garantire come condizione preliminare / asserzione che il chiamante sta effettivamente tenendo il lucchetto.

Per le classi con molte di tali funzioni interne, e forse molte funzioni pubbliche che le chiamano, si potrebbe garantire che qualcuno che aggiunge un'altra funzione pubblica che chiama quella interna abbia effettivamente acquisito il blocco.

class SynchronizedClass
{

public:

void publicFunc()
{
  std::lock_guard<std::mutex>(_mutex);

  internalFuncA();
}

// A lot of code

void newPublicFunc()
{
  internalFuncA(); // whops, forgot to acquire the lock
}


private:

void internalFuncA()
{
  assert(_mutex.is_locked_by_this_thread());

  doStuffWithLockedResource();
}

};