ICLRSyncManager::CreateRWLockOwnerIterator-Methode

Artikel
08/10/2011

Fordert, dass die Common Language Runtime (CLR) einen Iterator für den Host erstellt, um die Gruppe von Aufgaben zu bestimmen, die auf eine Reader/Writer-Sperre warten.

HRESULT CreateRWLockOwnerIterator (
    [in]  SIZE_T    cookie,
    [out] SIZE_T   *pIterator
);

Parameter

cookie
[in] Das der Reader/Writer-Sperre zugeordnete Cookie.
pIterator
[out] Ein Zeiger auf einen Iterator, der an die GetRWLockOwnerNext-Methode und die DeleteRWLockOwnerIterator-Methode übergeben werden kann.

Rückgabewert

HRESULT	Beschreibungen
S_OK	CreateRWLockOwnerIterator erfolgreich zurückgegeben.
HOST_E_CLRNOTAVAILABLE	Die CLR wurde nicht in einen Prozess geladen oder befindet sich in einem Zustand, in dem sie weder verwalteten Code ausführen noch den Aufruf erfolgreich verarbeiten kann.
HOST_E_TIMEOUT	Der Aufruf hat das Zeitlimit überschritten.
HOST_E_NOT_OWNER	Der Aufrufer ist nicht Besitzer der Sperre.
HOST_E_ABANDONED	Ein Ereignis wurde abgebrochen, während ein blockierter Thread oder eine blockierte Fiber auf das Ereignis gewartet hat.
E_FAIL	Ein unbekannter, schwerwiegender Fehler ist aufgetreten. Wenn eine Methode E_FAIL zurückgibt, kann die CLR innerhalb des Prozesses nicht mehr verwendet werden. Nachfolgende Aufrufe von Hostmethoden geben HOST_E_CLRNOTAVAILABLE zurück.
HOST_E_INVALIDOPERATION	CreateRWLockOwnerIterator wurde für einen Thread aufgerufen, der gerade verwalteten Code ausführt.

Hinweise

Hosts rufen während der Deadlockerkennung normalerweise die Methoden CreateRWLockOwnerIterator, DeleteRWLockOwnerIterator und GetRWLockOwnerNext auf. Der Host muss sicherstellen, dass die Reader/Writer-Sperre weiterhin gültig ist, da die CLR nichts unternimmt, um diese Sperre aufrechtzuerhalten. Mehrere Strategien sind verfügbar, damit der Host die Gültigkeit von der Sperre sicherstellt:

Der Host kann Freigabeaufrufe für die Reader/Writer-Sperre (z. B. IHostSemaphore::ReleaseSemaphore) blockieren und dabei sicherstellen, dass diese Blockade keinen Deadlock verursacht.
Der Host kann verhindern, dass beim Beenden das Ereignisobjekt erwartet wird, das der Reader/Writer-Sperre zugeordnet ist. Der Host muss wiederum sicherstellen, dass diese Blockade keinen Deadlock verursacht.