perché no hasLock / testLock su mutex

Il motivo è niente a che fare con condizioni di gara, o il metodo che restituisce un valore su cui non puoi fare affidamento:

• Se il thread corrente mantiene il blocco prima del test, è garantito per tenerlo dopo il test.

• Se il thread corrente non mantiene il blocco prima del test, non lo terrà premuto dopo il test.

Questa situazione cambierà solo se il thread esegue una chiamata per rilasciare (o acquisire) il blocco.

Penso che la vera ragione sia che un metodo holdLock() è di scarsa utilità per un'applicazione ben progettata.

Supponiamo che un thread chiami holdsLock() e restituisca true . Cosa dovrebbe fare il thread?

• Se il risultato è del tutto inaspettato, il thread è entrato in uno stato incoerente e probabilmente non ha altra opzione sicura se non quella di terminare l'applicazione. Ma potresti ottenere la stessa cosa (in modo più efficiente) semplicemente tentando la chiamata di lock e gestendo il codice di eccezione / errore che dice "hai già il blocco".

• Se il risultato è del tutto previsto, allora perché preoccuparsi del test? E quando si dice "debug", la risposta è che non è una buona idea impantanarsi in un metodo di libreria (eventualmente) critico delle prestazioni con un'infrastruttura di supporto per il debug. E (come indicato da Donal Fellows) ci sono problemi di stabilità, ecc. Se il supporto per il debug può essere disattivato e attivato.

• Se il risultato potrebbe essere andato in entrambi i modi, allora (presumibilmente) il thread dovrà impostare qualche flag / contatore, e condizionalmente acquisire e successivamente rilasciare condizionatamente il lock. (Se Acquisizione e Rilascio sono nello stesso metodo, allora una variabile locale lo farà, altrimenti hai creato un problema più grande.) Ma il vero punto è che se stai facendo efficacemente il blocco non rientranti funziona come un blocco rientrante . Un'idea migliore sarebbe quella di utilizzare semplicemente un blocco di rientro.

Probabilmente questo è il modo migliore per dire se hai in mano un mutex è che c'è un lock di poche righe in alto. Se i tuoi mutex vengono trattenuti più a lungo, il tuo software ha bisogno di rearchitecting.

Provi un blocco perché porta a condizioni di gara.

Le "uniche condizioni di gara possibili sono in # 3 ... e potrebbero essere irrilevanti" è una cattiva politica.

Una condizione di gara è semplicemente un difetto fatale nel design.

Ecco perché questi "test" non sono forniti.

Hai risposto molto bene alla tua domanda.

Inoltre, chiunque scriva un'applicazione utilizzando il test di blocco scriverà un'applicazione con una condizione di competizione.

Puoi solo afferrare o aspettare per afferrare un mutex; qualsiasi altra cosa (come un test) comporta la progettazione di una condizione di gara.

Non c'è assolutamente alcun motivo, dal punto di vista della funzionalità, di non aver incluso una funzionalità test-and-lock, e in precedenti lavori (ero uno sviluppatore del kernel AIX) l'ho usato con grande efficacia.

L'implementazione è banale: qualsiasi architettura che supporti operazioni di confronto e scambio può testare atomicamente l'impostazione di un blocco e acquisire il blocco allo stesso tempo. Se il confronto e il swap funzionano, hai il lucchetto e nessun altro può acquisirlo fino a quando non effettui il confronto e lo swap allo stato sbloccato. Se fallisce, qualcun altro ha il lucchetto.

In Java, è abbastanza semplice. Dichiara una variabile lunga. Sincronizza su quella variabile e controlla se è zero (sbloccato) o non zero. Se è zero, impostare il valore su Thread.currentThread (). GetId () e restituire true. Se è diverso da zero, impostalo su false. Quando hai finito, inverti il processo - sincronizza la variabile, imposta il suo valore su zero e il gioco è fatto.

Dipende da cosa si fa con uno schema di blocco che supporta la funzionalità di tipo test-and-lock. Dicendo "È male - non farlo!" è ingenuo.

Ne vedo diversi motivi.

• Innanzitutto, il risultato della funzione di controllo non sarà affidabile. Tra il momento in cui il test è terminato e il momento in cui usi quei dati, il risultato potrebbe essere cambiato, quindi il risultato è inutile.
• In secondo luogo, il costo dell'assegno sarebbe tanto elevato quanto un blocco / sblocco sul mutex stesso perché richiederà un'operazione atomica o - irronicamente - un altro mutex. Entrambe le operazioni sono costose.
• Terzo, perché è totalmente inutile. Il mutex è qui per proteggere un pezzo di codice / dati da utilizzare con 2 thread contemporaneamente. Non puoi fare nulla di utile delle informazioni di blocco di un mutex con quel pezzo di codice / dati senza rischiare condizioni di competizione. Potresti eventualmente loggare queste informazioni, ma perché non farlo nel codice che usa il mutex o avvolgendo il mutex in un decorratore? Ciò fornirà le stesse informazioni, a un costo ridotto e con risultati più accurati.

Considerando tutti gli usi pericolosi che potrebbero essere fatti con tale funzionalità, il fatto che i danni siano davvero difficili da individuare / debug e la mancanza di utilità della funzionalità, la scelta migliore è semplicemente quella di non fornire questa funzionalità.

Una fucilazione isHeldByCurrentThread sarebbe facile da implementare usando l'archiviazione locale dei thread e controllando un booleano qui. Il posto giusto per l'imputazione che si trova in un decoratore associato al mutex che aggiorna i valori sul blocco / rilascio del mutex (ad esempio). Ad ogni modo, dovresti essere già a conoscenza di queste informazioni finché hai bloccato quel mutex nel thread specificato.

Questo non è implementato nell'implementazione mutex standard perché ti deve essere il più veloce possibile e aggiornare un valore locale del thread sarebbe un'aggiunta del costo del blocco / rilascio così indesiderabile.

Inoltre, queste informazioni possono essere aggiunte da te al mutex abbastanza facilmente e non sono correlate ai problemi che hai ottenuto con la sincronizzazione, che sono abbastanza difficili da gestire per giustificare di per sé una separazione delle preoccupazioni tra il blocco stesso, e il calcolo del thread booleano locale per fornire un'informazione che dovresti già sapere.

Il test per il blocco è inutile, perché nel momento in cui ritorna vero o falso, la situazione è cambiata. Ridisegnare la semantica TryAcquire.

Inoltre, è possibile cercare poche righe per vedere se c'è una chiamata di blocco e in alcune implementazioni è possibile acquisire un blocco una seconda volta se lo si fa dallo stesso thread proprietario del blocco. Aiuta quando hai chiamate ricorsive.