Critical_Section, Vista und dual-core
-
hier mein fall, ich habe einen TThread(Borland, tut hier nichts zur sache)
dieser ist teil einer applikation, in der void execute() enter ich ständig eine CS und leave sie dann, greife ich jetzt aus der anwendung (kontext der oberfläche) auf eine bestimmte funktion der thread klasse zu VERSUCHE ich dieselbe CS zu entern (eigentlich im selben moment zwischen einem leave und einem enter der execute)ABER
es misslingt!!!
ich bleibe mit meinem aufruf an der entercriticalsection() hängen

baue ich ein sleep von 50ms zwischen einem leave und einem enter der execute methode funktioniert es wieder, aber das ist nicht wunschgemäß !
was hat sich an Critical_sections bezüglich multiprozessoren geändert ??
ich habe es mit InitializeCriticalSectionAnSpincount(&CS, 4000); versucht aber auch das misslang ....
-
ich glaube, das dein Problem mit einem dual-core mal gar nix zu tun hat und genau so auf SingleCore auftretten kann

-
ich bleibe mit meinem aufruf an der entercriticalsection() hängen

vielleicht sperrst du dich selber aus?
-
nein das muss ich wiederlegen, hab es doch noch in der MSDN gefunden!!! auf single core und multicore bis windows XP gilt "first come first serve" also wer zuerst ansteht bekommt auch zuerst.
seit Windows Server 2003 SP1 ist das nicht mehr so!!! es wird empfohlen anderweitig zu synchronisieren wenn eine fifo-struktur benötigt wird.Quelle: http://msdn2.microsoft.com/en-us/library/ms682530.aspx
ausserdem habe ich für critical sections einfach eine struktur genommen mit einem ctor ala mystruct(&CS);
in dem ctor steht dannstruct mystruct { CRITICAL_SECTION* CSH; mystruct(CRITICAL_SECTION* aCS) { CSH = aCS; EnterCriticalSection(CSH); } ~mystruct() { LeaveCriticalSection(CSH); } }in der anwendung mach ich einfach am anfang der methode
mystruct SECURE_OBJ(&CS);wenn ich die methode verlasse wird automatisch leave ausgeführt
-
ok Quelle gefunden
-
@Ceos: kann schon sein dass es bei XP so implementiert war, aber garantiert war FIFO noch nie. Da sieht man wieder mal dass es wichtig ist nach der Duko zu programmieren, und nicht nach dem beobachteten Verhalten.
-
naja FIFO hab ich nicht vorausgesetzt, aber das nach einem leave der erstbeste wartende enter drankommt hab ich eigentlich erwartet .... egal habs ERSTMAL mit nem sleep(0) gefixt, aber die feine englische isses natürlich nicht
-
Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum WinAPI verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Ja, ok, wenn man es so sieht...
Hast schon irgendwie recht...
In dem Moment wo das "leave" passiert wartet der Thread welcher "leave" macht ja noch nicht wieder, andere aber schon. Eigentlich sollte der die Ownership gleich ohne irgendwelche Spielchen an den nächsten wartenden Thread übertragen und den aufwecken...
Hmmm.
Keine Ahnung wieso sie das geändert haben. Wäre mal interessant den Code durchzusteppen... und bissi zu profilen ob der neue Code schneller ist als der alte.
Dass die Änderung für den Support von Condition Variablen notwändig war bezweifle ich auf jeden Fall stark, denn die kann man auch in Windows XP relativ schön mit einer CS machen. Hmmmmmmm. *wunder*
-
ich weis ja nich ob ich mit damit zu weit ausm fenster lehne aber benutzt die funktion waitforsingleobject() nicht CS zum handling ?????
wenn ja wäre auch nicht mehr gewährleistet das ein thread der am waitfor hängt auch ausgelöst wird.
desweiteren würd ich gern nach ner alternative frage, was man statt ner CS einsetzen kannn um z.B. einem vector des thread, den er permanent abarbeitet, einen wert aus eiem anderen thread heraus zu adden.