PureBoard

Verfasst: **25.01.2009 21:57**

PB und Threads sind wohl wie Feuer und Wasser.

Wenn man sich anschaut was PB da macht:

push    eax
push    dword_x
call    TlsGetValue
mov     edx, [eax]
pop     eax
retn

Soweit so gut, hier wird der von PB angelegte Thread Local Storage ausgelesen.
Das dumme ist nur - es wird nicht geprüft ob das Lesen überhaupt funktioniert hat!
Denn das kann bei Threads auch mal nicht funktionieren weil ein anderer Thread noch darauf zugreift.

Der zweite Versuch schlägt Fehl und im Register EAX ladet der Return NULL.
NULL weils eben nicht funktioniert hat. (siehe WINAPI Doku. zu TLS)
Und natürlich gibt es später einen Exception Fehler wenn man versucht von NULL zu lesen.

In deinem Fall kannst du den Fehler umgehen indem du z.B. folgendes machst:

Code: Alles auswählen

GetCursorPos_(@MausPosition.POINT)
SetGadgetText(#MausPosX, Str(MausPosition\x))
Delay(50)
SetGadgetText(#MausPosY, Str(MausPosition\y))
Delay(50)

Das ist jedoch keine Garantie das es nicht wieder passieren kann,
an der Stelle geben wir Windows nur etwas mehr Zeit den TLS wieder freizugeben.

Verfasst: **25.01.2009 22:56**

msschlt hat geschrieben:Das dumme ist nur - es wird nicht geprüft ob das Lesen überhaupt funktioniert hat!
Denn das kann bei Threads auch mal nicht funktionieren weil ein anderer Thread noch darauf zugreift.

Der zweite Versuch schlägt Fehl und im Register EAX ladet der Return NULL.
NULL weils eben nicht funktioniert hat. (siehe WINAPI Doku. zu TLS)

Vielleicht solltest du die Doku selber mal lesen

(siehe WINAPI Doku. zu TLS) hat geschrieben:If dwTlsIndex is a valid index allocated by a successful call to TlsAlloc, this function always succeeds.

Verfasst: **25.01.2009 23:02**

Weiter unten steht aber:

Code: Alles auswählen

If the function fails, the return value is zero.

Und da der Index auf jedenfall "valid" ist, da er der gleiche ist wie im ersten Versuch,
ist der Fehler logischer Weise eine Thread bedingte Sperre des Datensatzes durch Windows.

Verfasst: **25.01.2009 23:17**

Das passiert aber nur bei inkorrekter Eingabe.

Wenn man klugscheißern will sollte man wenigstens wissen wovon man redet. Ein Satz wie:

Denn das kann bei Threads auch mal nicht funktionieren weil ein anderer Thread noch darauf zugreift.

ist schlichtweg Schwachsinn.

Und da der Index auf jedenfall "valid" ist, da er der gleiche ist wie im ersten Versuch,
ist der Fehler logischer Weise eine Thread bedingte Sperre des Datensatzes durch Windows.

Die Doku garantiert aber das korrekter Input immer zu korrektem Output führt. Du redest also ziemlichen Mist hier.

Verfasst: **25.01.2009 23:30**

Denn das kann bei Threads auch mal nicht funktionieren weil ein anderer Thread noch darauf zugreift.

Wenn das Schwachsinn ist dann sag wofür z.b. TryEnterCriticalSection gut ist, oder in PB TryLockMutex?

Entschuldigung das ich mich dazu hinreißen ließ anzunehmen
TlsGetValue arbeite intern evtl. wie TryEnterCriticalSection.
Wahrscheinlich muß ich mich das nächste mal einfach deutlicher ausdrücken.

Ich weiss sehr wohl was ich tue und muss sagen das
Niveau in diesem Forum hat schwer nachgelassen.

Punkt ist TlsGetValue bringt eine NULL zurück und das obwohl der Slot Index korrekt ist und
wenn ich das mit dem Debugger richtig sehe dann da in diesem Fall kein TlsSetValue vor
dem TlsGetValue im entsprechendem Thread ausgeführt wird.

Verfasst: **27.01.2009 17:19**

Die Doku garantiert aber das korrekter Input immer zu korrektem Output führt. Du redest also ziemlichen Mist hier.

It is up to the programmer to ensure that the index is valid and that the thread calls TlsSetValue before calling TlsGetValue.

Nix Mist, Bug

Verfasst: **27.01.2009 17:26**

msschlt hat geschrieben:
It is up to the programmer to ensure that the index is valid and that the thread calls TlsSetValue before calling TlsGetValue.
Nix Mist, Bug

Sry für's Einmischen, ich hab kein Plan von Threads, aber der Satz heißt, dass du als Programmierer selber dafür zu sorgen hast, dass dein Thread funktioniert, in dem du die Reihenfolge der Funktionen beachtest. Also nix Bug. Ist doch auch kein Bug, wenn du deinen Fön in die Badewanne schmeißt und danach hin bist. Da steht doch schon, wie's richtig geht.

Verfasst: **27.01.2009 17:44**

Jain. Natürlich sollte man sich bei Threads selber darum kümmer.
Allerdings macht PB dies u.a. bei Strings und der Kompiler Option
"Create threadsafe executable" selbst.

Wenn man wie schon erwähnt das Ganz erst in Strings auslagert:

Code: Alles auswählen

GetCursorPos_(@MausPosition)
x.s = Str(MausPosition\x)
y.s = Str(MausPosition\y)
SetGadgetText(#MausPosX, x)
SetGadgetText(#MausPosY, y)

..dann macht PB auch das TlsSetValue vor dem TlsGetValue.

Bei dem Beispiel von Armkrie fehlt es nunmal, schaut es euch selbst mit nem Debugger an.
Warum PB das TlsSetValue vergißt kann ich euch auch nicht sagen.

Der Vergleich mit dem Fön greift nicht da der Code vom Armkrie nicht "fahrlässig" ist.
Das ist ganz klar ein Bug.

Verfasst: **27.01.2009 19:27**

Das es einen Bug gibt bestreitet ja keiner.

Aber vielleicht solltest du das Suchen der Ursache dem überlassen der sich mit der Materie auskennt und vorallem den Code vor sich hat (Fred).
Hier mit deinem Halbwissen einen auf superschlau machen zu wollen ging nämlich ziemlich in die Hose.

Entschuldigung das ich mich dazu hinreißen ließ anzunehmen
TlsGetValue arbeite intern evtl. wie TryEnterCriticalSection.
Wahrscheinlich muß ich mich das nächste mal einfach deutlicher ausdrücken.

Nein, du solltest das nächste mal dich vorher informieren wie thread local storage überhaupt funktioniert bzw. was der Sinn der Sache ist dann wäre dir gleich aufgefallen das das Schwachsinn ist.

Verfasst: **27.01.2009 20:00**

Sag mal freak wo ist eigentlich dein Problem?

Halbwissen kannst du mir vielleicht vorwerfen da
ich den Code von PB nicht vor mir habe.

Wie Threads, Semaphoren und TLS funktioniert weiß ich sehr wohl.
Ich nutze sie in meinen Programmen und ich prüfe zumindest auch
den Return von TlsGetValue. Denn wenn man eines in der Windows
Geschichte lernen konnte dann sind es "Unknow Errors".

Des weiteren hast du mir noch immer nicht erklärt was
und warum in deinen Augen Schwachsinn ist.
Denn je nach dem wie man es in einem Programm brauch
kann es sehr wohl von nutzen sein wenn ein Thread weiter
arbeiten kann in dem als Beispiel TryEnterCriticalSection eben
nicht wartet wie EnterCriticalSection.

Aber da ich nun weiß das TlsSetValue wartet werde ich
in entsprechend Zeit kritischen Threads evlt. davon absehen.

Hier mit deinem Halbwissen einen auf superschlau machen zu wollen ging nämlich ziemlich in die Hose.

Und deine beleidigende Art kannste in Zukunft bitte auch stecken lassen.

PureBoard

Fehler bei Str in Thread