Esiste uno scenario, ho due thread che utilizzano entrambi lo stesso mutex. Un thread ha bloccato il mutex e si è bloccato. Quale sarebbe lo stato mutex? È ancora bloccato e il secondo thread non possiede mai quel mutex? Significa una situazione di deadlock?Il thread si è bloccato con Mutex bloccato
Edit - spiegano anche un caso di pthread su sistemi Linux
Dal momento che non è stato specificato quale sistema operativo, vi dirò ciò che accade in Win32.
In Win32, il secondo thread otterrebbe WAIT_ABANDONED quando va in attesa sul mutex posseduto da un thread terminato. Nota che ricevere WAIT_ABANDONED significa che il secondo thread ha ricevuto il mutex, quindi non ci sarà un deadlock. Il secondo thread dovrebbe rilevare il risultato WAIT_ABANDONED e verificare che la risorsa protetta dal mutex sia in uno stato valido. Se è in grado di rilevare la corruzione e non ne rileva, è sicuro procedere. In caso contrario, è una buona idea sollevare un errore di qualche tipo.
Con alcune implementazioni di un mutex non c'è modo di rilevare che il thread che lo possiede è terminato e si finisce con un deadlock.
Con alcune implementazioni di un mutex esiste un modo per rilevare il thread proprietario, capire che il thread proprietario è terminato e quindi assumere la proprietà del mutex.
in alcune implementazioni è possibile definire il tempo di attesa o creare il proprio metodo wrapper ... comunque, la sospensione del thread non ha alcun effetto su mutex \ semaphore nell'implementazione classica quindi è consigliabile controllare il tempo di attesa e aumentare l'eccezione di timeout o riprendere l'esecuzione. – Oleksandr
Ci scusiamo per mezza domanda. Questo è su sistema operativo Windows e piace anche conoscere l'altro comportamento del sistema operativo. Gabe: Se si ottiene sempre WAIT_ABANDONED, allora può essere gestito facilmente. Di nuovo, c'è un punto morto? Come rileviamo il thread del proprietario è andato in crash. Joonas Pulakka: Si supponga che il thread si sia arrestato in modo anomalo con NULL. Non fa eccezione o nessun riconoscimento. La domanda – CrazyC
Che certamente dipende (almeno) due cose:
Per esempio, in synchronized blocchi di Java sono garantiti per essere rilasciato quando il "filo è fatto con l'oggetto" - qualunque cosa significhi (vedi link). Secondo this articolo:
L'interruzione di un thread provoca il blocco di tutti i monitor che ha bloccato.
Ok, stop() ing i rilasci filo i monitor, ma cosa succede se un filo scompare in qualche modo, è poi "fatto con l'oggetto"? Non vedo questo documentato da nessuna parte. Ma è ovvio che qualcuno deve rilasciare mutex bloccati o altrimenti si bloccherà; forse alcuni mutex o ambienti includono meccanismi che rilasciano mutex automaticamente se il thread, che li ha bloccati, diventa inesistente.
Un altro esempio: java.util.concurrent.Lock documenti consiglia di utilizzare una dichiarazione finally per rilasciare il blocco in modo che qualsiasi cosa accada con il thread in esecuzione, il blocco venga rilasciato. Ma, se il thread scompare prima che venga eseguita l'istruzione finally, il blocco non viene mai rilasciato e si verifica effettivamente un deadlock. Ovviamente, i thread non dovrebbero "scomparire" proprio così.
Una bella domanda!
è buona, ma ogni implementazione ha il proprio meccanismo e una soluzione per risolvere il problema descritto, ma potremmo solo indovinare che cosa significa l'autore :) – Oleksandr
Grazie per la risposta. http://msdn.microsoft.com/en-us/library/ms687032%28VS.85%29.aspx MSDN dice anche che rilascia il mutex e che i thread in attesa ottengono lo stato WAIT_ABANDONED.
Si prega di fornire ulteriori informazioni. – InsertNickHere