Bug in Windows (10) gefunden?

[Bonita.M]

hustbaer schrieb:

Achherrjeh, Bonita, ich weiss was rekursive Mutexen sind und wie sie funktionieren. Ich weiss auch was du dir dabei gedacht hast. Ich versuche dir nur zu erklären dass es trotzdem unsinnig ist. Es maskiert gefährliche Anwendungsfehler.

Das doppelte Locken und darin das Wait mag in der Praxis kaum vorkommen, aber es ist kein Anwendungsfehler. Ich finde es nicht falsch diesen seltenen Fall mit zu unterstützen.
Hättest Du dich direkt von Anfang an vollständig und nicht mehrdeutig ausgedrückt, dann hätte ich deine seltsamen Bedenken gleich verstanden. Das hast Du aber nicht.

[hustbaer]

Es ist sehr oft ein Anwendungsfehler. Und wenn es keiner ist, dann ist das rekursive Locken vermeidbar. Es gibt also keinen Grund Wait einen rekursiven Unlock machen zu lassen. Es gäbe dagegen gute Gründe in Wait ein assert() einzubauen um abzusichern dass der Fall eben nicht auftritt.

Aber du weisst ja alles besser.

[hustbaer]

Bonita.M schrieb:

Hättest Du dich direkt von Anfang an vollständig und nicht mehrdeutig ausgedrückt, dann hätte ich deine seltsamen Bedenken gleich verstanden. Das hast Du aber nicht.

Ja, klar, liegt bestimmt an mir.
Muss so sein. Du machst ja keine Fehler. Und verstehst auch alles.

[Bonita.M]

hustbaer schrieb:

Es ist sehr oft ein Anwendungsfehler. Und wenn es keiner ist, dann ist das rekursive Locken vermeidbar. Es gibt also keinen Grund Wait einen rekursiven Unlock machen zu lassen. Es gäbe dagegen gute Gründe in Wait ein assert() einzubauen um abzusichern dass der Fall eben nicht auftritt.

Man kann nicht 100%ig ausschließen, dass jemand sowas absichtlich macht und der Code korrekt ist. Daher ist ein assert() hier falsch.

hustbaer schrieb:

Ja, klar, liegt bestimmt an mir.
Muss so sein. Du machst ja keine Fehler. Und verstehst auch alles.

Ja, das liegt an dir. Z.B. sprachst Du vom doppelten Locken, wobei nicht klar war ob Du damit ein verschachteltes Locken meinst oder ein Locken in zwei Threads. Das ist nicht die einzige Uneindeutigkeit mit der Du kommst. Du vervollständigst deine Aussagen nach und nach, und kommst nicht direkt von Anfang an mit Klarheit.

[Win10BugFinderLober]

Bonita.M schrieb:

löschen

Zuletzt bearbeitet von Bonita.M am 14:45:49 27.05.2016, insgesamt 2-mal bearbeitet

Bonita.M schrieb:

Zuletzt bearbeitet von Bonita.M am 18:11:11 27.05.2016, insgesamt 10-mal bearbeitet

Bonita.M schrieb:

Zuletzt bearbeitet von Bonita.M am 18:23:06 27.05.2016, insgesamt 3-mal bearbeitet

Ich kommentiere das jetzt mal nicht.

[Bonita.M]

Win10BugFinderLober schrieb:

Ich kommentiere das jetzt mal nicht.

Wäre besser wenn mein Vorredner auch mal die Editierfunktion genutzt hätte und sich klar ausgedrückt hätte.

[hustbaer]

Bonita.M schrieb:

hustbaer schrieb:

Es ist sehr oft ein Anwendungsfehler. Und wenn es keiner ist, dann ist das rekursive Locken vermeidbar. Es gibt also keinen Grund Wait einen rekursiven Unlock machen zu lassen. Es gäbe dagegen gute Gründe in Wait ein assert() einzubauen um abzusichern dass der Fall eben nicht auftritt.

Man kann nicht 100%ig ausschließen, dass jemand sowas absichtlich macht und der Code korrekt ist. Daher ist ein assert() hier falsch.
Außerdem: das mit dem doppelten Locken und dann warten geht mit der Condvar von Win32 auch. Ich habe eine testweise Ersatzklasse für meine, die die CondVar von Win32 nutzt. Da funktioniert das auch.

Also du erlaubst lieber etwas was sonst keine Implementierung erlaubt, und was sehr oft ein Anwendungsfehler ist... als ein assert einzubauen das dem User sagt dass er vermutlich 'was falsch macht.
Sehr intelligent.
Genau das meinte ich mit

hustbaer schrieb:

ps: Natürlich ist das dein Code, und du kannst definieren was du willst. Du kannst also auch definieren dass dein cv::Wait dieses verhalten hat. Dann ist es kein Fehler. Dann ist nur deine cv Klasse ein nutzloses Teil von dem man besser die Finger lassen sollte.

Bonita.M schrieb:

Ja, das liegt an dir. Z.B. sprachst Du vom doppelten Locken, wobei nicht klar war ob Du damit ein verschachteltes Locken meinst oder ein Locken in zwei Threads. Das ist nicht die einzige Uneindeutigkeit mit der Du kommst. Du vervollständigst deine Aussagen nach und nach, und kommst nicht direkt von Anfang an mit Klarheit.

Ich habe z.B. geschreiben "Wait aufzurufen während man die Mutex doppelt gelockt hat ist ein Anwendungsfehler. "
Wie sollen bitte zwei Threads die Mutex gleichzeitig gelockt haben? Damit kann nur gemeint sein rekursiv im selben Thread.
Oder auch

hustbaer schrieb:

Den Fall dass Wait mit dwSavedRecusionCount > 1 aufgerufen wird solltest du einfach nur mit assert() verbieten bzw. ggf. abort() aufrufen. Die Mutex einfach so aufzumachen ist mMn. einfach nur falsch. Grob falsch. Gefährlich falsch.

Mal abgesehen davon dass ich hier besser m_dwRecursionCount statt dwSavedRecusionCount schreiben hätte sollen... was ist daran bitte unklar?

Du musst bloss lesen lernen.

[Bonita.M]

hustbaer schrieb:

Ich habe z.B. geschreiben "Wait aufzurufen während man die Mutex doppelt gelockt hat ist ein Anwendungsfehler. "

Doppelt gelockt könnte ja auch zweimal aus zwei Threads Enter aufgerufen zu haben bedeuten, und nicht zweimal gleichzeigig erfolgreich gelockt.

hustbaer schrieb:

Den Fall dass Wait mit dwSavedRecusionCount > 1 aufgerufen wird solltest du einfach nur mit assert() verbieten bzw. ggf. abort() aufrufen. Die Mutex einfach so aufzumachen ist mMn. einfach nur falsch. Grob falsch. Gefährlich falsch.

Daran ist garnichts gefährlich. Wenn die CV richtig gehandhabt wird ist das funktionierender Code. Und da sowas in der Praxis eh nicht vorkommt ist das eigentlich egal.

[hustbaer]

lol
Tu was du willst. Glaub was du willst.
Ich hab hier schon viel zu viel Zeit verschwendet.

[EOP]

Ein quengeliges, egozentrisches und von sich selbst übermäßig überzeugtes Weib - der Grund wieso ich mich von meiner letzten Frau getrennt habe.

EDIT:
6 mal editiert nur weil ich nicht wusste wie man "quengelig" richtig schreibt.

EDIT#2:
http://www.duden.de/rechtschreibung/quengeln#b2-Bedeutung-1

[hustbaer]

Ich denke nicht dass das jetzt 'was zur Sache tut.

[EOP]

hustbaer schrieb:

Ich denke nicht dass das jetzt 'was zur Sache tut.

Hat zugegebenerweise nur bedingt was mit der Sache zu tun. Nur weil mich die Verhaltensweise dieser lieblichen Bonita aber an gewisse Verhaltensweisen erinnert hat. Man darf ja wohl auch manchmal etwas abschweifen. Oder nicht?

[Bonita.M]

In einem anderen Forum hatte jemand eine gute Idee für einen Workaround: einfach für beide Thread-Typen zusätzlich auf ein immer gesetztes manual-reset Event warten lassen, im einen Fall wird dann natürlich aus einem WaitForSingleObject ein WaitForMultipleObjects. So funktioniert das und der Haupt-Thread bekommt auch CPU-Zeit und hungert nicht aus.

So sieht der Test-Code jetzt aus:

#include <windows.h>
#include <cstdio>
#include <unordered_map>

HANDLE        hEvt,
              hSema,
              hEvtAlwaysSet;
bool volatile fReleased;

DWORD WINAPI LockAndReleaseThread( LPVOID lpvThreadParam );

int main()
{
	int const NTHREADS = 2;
	HANDLE    ahWait[3];

  	ahWait[0] = ::hEvt          = CreateEvent( NULL, FALSE, TRUE, NULL );
	ahWait[1] = ::hSema         = CreateSemaphore( NULL, 0, 1, NULL );
	ahWait[2] = ::hEvtAlwaysSet = CreateEvent( NULL, TRUE, TRUE, NULL );
	fReleased = false;

	for( int i = 0; i < NTHREADS; i++ )
		CreateThread( NULL, 0, LockAndReleaseThread, NULL, 0, NULL );

	for( ; ; )
		WaitForMultipleObjects( 3, ahWait, TRUE, INFINITE ),
		std::printf( "main thread is holding lock and received signal\n" ),
		::fReleased = false,
		SetEvent( ::hEvt );

    return 0;
}

char GetID();

DWORD WINAPI LockAndReleaseThread( LPVOID lpvThreadParam )
{
	HANDLE ahWait[2] = { ::hEvt, ::hEvtAlwaysSet };

	for( ; ; )
	{
		WaitForMultipleObjects( 2, ahWait, TRUE, INFINITE );
		std::printf( "spawned thread with id %c is holding lock\n", (char)GetID() );

		if( !::fReleased )
			ReleaseSemaphore( ::hSema, 1, NULL ),
			::fReleased = true;

		Sleep( 1000 );
		SetEvent( ::hEvt );
	}

	return 0;
}

char GetID()
{
	static std::unordered_map<DWORD, char> mapTIDsToIDs;
	static char                            nextId = 'A';
	DWORD                                  dwThreadId;

	if( mapTIDsToIDs.find( dwThreadId = GetCurrentThreadId() ) == mapTIDsToIDs.end() )
		return mapTIDsToIDs[dwThreadId] = nextId++;
	else
		return mapTIDsToIDs[dwThreadId];
}