TCondVar kaputt oder Denkfehler meinerseits?

Übersicht

BlitzMax, BlitzMax NG

Allgemein

	BtbN Betreff: TCondVar kaputt oder Denkfehler meinerseits?	Mi, Jan 27, 2010 18:12 Antworten mit Zitat
Folgender Code: BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] SuperStrict Framework BRL.Threads Global mut:TMutex = TMutex.Create() Global cond:TCondVar = TCondVar.Create() mut.Lock() cond.Wait(mut) mut.Unlock() WriteStdout("Juche!~n") End Gibt sofort Juche! aus. Aber nach allem was ich über CondVars weiß, müsste das ganze für immer einfrieren, da niemand jemals die Signal oder Broadcast Methode der CondVar aufrufen wird. Stehe ich hier aufm Schlauch, oder ist das echt nen Fehler in der implementation der CondVars? Mfg

BtbN

Betreff: TCondVar kaputt oder Denkfehler meinerseits?

Mi, Jan 27, 2010 18:12
Antworten mit Zitat

Folgender Code:

BlitzMax: [AUSKLAPPEN]

SuperStrict

Framework BRL.Threads

Global mut:TMutex = TMutex.Create()
Global cond:TCondVar = TCondVar.Create()

mut.Lock()
cond.Wait(mut)
mut.Unlock()

WriteStdout("Juche!~n")

End

Gibt sofort Juche! aus. Aber nach allem was ich über CondVars weiß, müsste das ganze für immer einfrieren, da niemand jemals die Signal oder Broadcast Methode der CondVar aufrufen wird.
Stehe ich hier aufm Schlauch, oder ist das echt nen Fehler in der implementation der CondVars?

Mfg

	Dreamora	Mi, Jan 27, 2010 18:52 Antworten mit Zitat
is nix falsch in der logik. du hast nur keinen zweiten thread der den mutex lockt, er kann also direkt rein und es nutzen und hinten wieder raus
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mi, Jan 27, 2010 18:52
Antworten mit Zitat

is nix falsch in der logik.
du hast nur keinen zweiten thread der den mutex lockt, er kann also direkt rein und es nutzen und hinten wieder raus Smile

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	BtbN	Mi, Jan 27, 2010 18:53 Antworten mit Zitat
Eben, da ich keinen 2ten Thread habe, müsste das ding ja für Immer warten, tut es aber nicht. Wie Smily mir bestätigt hat, tritt das Problem unter MacOS nicht auf, und somit auch unter Linux nicht, da MacOS und Linux den selben code nutzen.

BtbN

Mi, Jan 27, 2010 18:53
Antworten mit Zitat

Eben, da ich keinen 2ten Thread habe, müsste das ding ja für Immer warten, tut es aber nicht.
Wie Smily mir bestätigt hat, tritt das Problem unter MacOS nicht auf, und somit auch unter Linux nicht, da MacOS und Linux den selben code nutzen.

	Dreamora	Mi, Jan 27, 2010 19:17 Antworten mit Zitat
rein von der mutex logic her müsste er locken, ja. Ich nehm mal an threaded build ist aktiv? Eventuell 1.3.6? (-> in dem fall versuch mach die prozeduralen lock - wait - unlock, gibt behauptungen das die oop mutex - condvar etc methoden angeblich spinnen. Habs net überprüft)
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mi, Jan 27, 2010 19:17
Antworten mit Zitat

rein von der mutex logic her müsste er locken, ja.

Ich nehm mal an threaded build ist aktiv?
Eventuell 1.3.6? (-> in dem fall versuch mach die prozeduralen lock - wait - unlock, gibt behauptungen das die oop mutex - condvar etc methoden angeblich spinnen. Habs net überprüft)

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Zuletzt bearbeitet von Dreamora am Mi, Jan 27, 2010 19:19, insgesamt einmal bearbeitet

	BtbN	Mi, Jan 27, 2010 19:18 Antworten mit Zitat
Ohne threaded build würds nicht gehen, und wieso sollten die methoden nicht gehen? Die funktions-wrapper rufen diese nur auf. Scheint eindeutig nen bug in der Win32-Implementierung zu sein.

BtbN

Mi, Jan 27, 2010 19:18
Antworten mit Zitat

Ohne threaded build würds nicht gehen, und wieso sollten die methoden nicht gehen? Die funktions-wrapper rufen diese nur auf.
Scheint eindeutig nen bug in der Win32-Implementierung zu sein.

	Dreamora	Mi, Jan 27, 2010 19:20 Antworten mit Zitat
frag mich net warums net gehen sollte vielleicht ein fehler in der win32 implementierung, vielleicht auch ein unterschied von windows zu *nix im threadhandling wenn der gleiche thread der lockt versucht drauf zuzugreifen (es also kein externes lock gibt), in welchem falle es keinen realistischen grund gibt den zugriff zu verweitern da du ja das lock bereits hast im thread (garantiert!)
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mi, Jan 27, 2010 19:20
Antworten mit Zitat

frag mich net warums net gehen sollte Smile

vielleicht ein fehler in der win32 implementierung, vielleicht auch ein unterschied von windows zu *nix im threadhandling wenn der gleiche thread der lockt versucht drauf zuzugreifen (es also kein externes lock gibt), in welchem falle es keinen realistischen grund gibt den zugriff zu verweitern da du ja das lock bereits hast im thread (garantiert!)

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	BtbN	Mi, Jan 27, 2010 19:21 Antworten mit Zitat
Das ganze ist schlicht und ergreifend ein reduzierter Test, der Unter Unix geht, unter Windows nicht. Die implementierung von den dingern unter win ist eh sehr abenteuerlich. Edit: Selbst doppeltes locken eines Mutex scheint den nicht zu interessieren. Sieht bald so aus, als wenn Mutex unter Win32 komplett ohne funktion wäre?!

BtbN

Mi, Jan 27, 2010 19:21
Antworten mit Zitat

Das ganze ist schlicht und ergreifend ein reduzierter Test, der Unter Unix geht, unter Windows nicht. Die implementierung von den dingern unter win ist eh sehr abenteuerlich.

Edit: Selbst doppeltes locken eines Mutex scheint den nicht zu interessieren. Sieht bald so aus, als wenn Mutex unter Win32 komplett ohne funktion wäre?!

	Dreamora	Mi, Jan 27, 2010 19:25 Antworten mit Zitat
BtbN hat Folgendes geschrieben: Das ganze ist schlicht und ergreifend ein reduzierter Test, der Unter Unix geht, unter Windows nicht. Die implementierung von den dingern unter win ist eh sehr abenteuerlich. Hab ich mir nie angesehen, da ich sie net nutze im moment und drum keinen grund hab bugs zu jagen in den modulen Rein von der effizienz / korrektheits logik her wäre ich gezwungen an der *nix implementation zu zweifeln, wenn es mir (hauptthread), der das lock besitzt, beim versuch von condvar.wait den thread blocken würde, denn ich besitze ja das lock bereits!
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mi, Jan 27, 2010 19:25
Antworten mit Zitat

BtbN hat Folgendes geschrieben:

Das ganze ist schlicht und ergreifend ein reduzierter Test, der Unter Unix geht, unter Windows nicht. Die implementierung von den dingern unter win ist eh sehr abenteuerlich.

Hab ich mir nie angesehen, da ich sie net nutze im moment und drum keinen grund hab bugs zu jagen in den modulen Wink

Rein von der effizienz / korrektheits logik her wäre ich gezwungen an der *nix implementation zu zweifeln, wenn es mir (hauptthread), der das lock besitzt, beim versuch von condvar.wait den thread blocken würde, denn ich besitze ja das lock bereits!

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Übersicht

BlitzMax, BlitzMax NG

Allgemein

Nach Oben

BlitzBasic Portal

TCondVar kaputt oder Denkfehler meinerseits?

Betreff: TCondVar kaputt oder Denkfehler meinerseits?