Enter/Leave Critical SEction
-
Bin grad bischen am "Mutlirthreaden" und Syncronisieren! und es Funktionier bisher wundderbar:) Nun eine Frage, was passiert wenn zwei Thread auf die gleiche Ressoruce zugreifen wollen, udn beide exakt zur gleichen zeit
EnterCriticalSection aurufen? Gibts dann nen Deadlock, oder its sowas nicht möglich?
-
BorisDieKlinge schrieb:
Bin grad bischen am "Mutlirthreaden" und Syncronisieren! und es Funktionier bisher wundderbar:) Nun eine Frage, was passiert wenn zwei Thread auf die gleiche Ressoruce zugreifen wollen, udn beide exakt zur gleichen zeit
EnterCriticalSection aurufen? Gibts dann nen Deadlock, oder its sowas nicht möglich?Du schreibst eigentlich schon lange genug in dem Forum um zu wissen, das Threads nicht Ansi C++ sind und du je nach Bibliothek ggf. in einen anderen Unterforum zu posten hast. Zudem wäre es auch mal gut zu erfahren welche Threading-Bibliothek du einsetzt.
cu André
-
beim multithreading warten bei simultanen zugriff auf resourcen deadlocks an jeder ecke
und genau deshalb gibs in jeder lib entsprechende mechanismen, um solche zugriffe zu koordinieren.grundsätzlich kann man dabei wohl sagen, dass aktives warten (polling) weniger anfällig gegen deadlocks ist, als passives warten. beim aktiven warten kann jeder thread selbst entscheiden, ob eine resource vielleicht doch nicht verfügbar ist (timeout), beim passiven warten kann die ganze app zum stehen kommen, wenn der supervisor sich verabschiedet.
musst einfach mal in die doku deiner lib gucken, was die dafür anbietet.
und noch ne anmerkung: auch bei multithreading gibt es kein "gleichzeitig". selbst die tollste nebenläufige anwendung muss irgendwann mal sequentiell verarbeitet werden. deshalb trifft die grundannahme, "irgendwer kommt zuerst" immer zu und erlaubt anständige koordination von kritischen zugriffen.
worauf allerdings penibel geachtet werden muss ist, dass die sperrung des zugriffes auf eine resource, eine atomare operation ist. d.h. sie darf nicht unterbrochen werden. wenn das nämlich passiert, dann ist nen deadlock schon vorprogrammiert.
-
thordk schrieb:
und noch ne anmerkung: auch bei multithreading gibt es kein "gleichzeitig". selbst die tollste nebenläufige anwendung muss irgendwann mal sequentiell verarbeitet werden. deshalb trifft die grundannahme, "irgendwer kommt zuerst" immer zu und erlaubt anständige koordination von kritischen zugriffen.
Mit Dual Core Prozessoren immer noch??
BorisDieKlinge schrieb:
Nun eine Frage, was passiert wenn zwei Thread auf die gleiche Ressoruce zugreifen wollen, udn beide exakt zur gleichen zeit
EnterCriticalSection aurufen? Gibts dann nen Deadlock, oder its sowas nicht möglich?Dann wäre multithreading ja nur noch Glücksspiel.
-
neee, die hohe kunst des multithreading programmierens ist ja, die Locks so minimal zu halten.
Also entscheiden, ob gemeinsammer zugriff auf eine ressource, oder einmaliges kopieren der ressource und dann die threads auf den kopien arbeiten lassen, besser ist ....Gemeinsam genutzte ressourcen muss man locken, die frage ist eigentlich, sind gemeinsam genutzte ressourcen immer notwendig ?
wobei rein lesende zugriffe schon parrallel gehen ...
Ciao ...
-
asc schrieb:
Zudem wäre es auch mal gut zu erfahren welche Threading-Bibliothek du einsetzt.
BorisDieKlinge schrieb:
...EnterCriticalSection...
ich tippe auf Win32 API
BorisDieKlinge schrieb:
was passiert wenn zwei Thread auf die gleiche Ressoruce zugreifen wollen, udn beide exakt zur gleichen zeit
EnterCriticalSection aurufen? Gibts dann nen Deadlock, oder its sowas nicht möglich?das hängt wohl von der ressource/der art des zugriffs ab...
-
außerdem sind lesezugriffe imho unproblematisch
und für gleichzeitige schreibzugriffe gibts ja dann
den asm lock bzw. die api wrapper
-
also um mal auf das EnterCriticalSection() zu schliessen, nein selbst bei multicore kommt es mit dem momentanen c++ standard unmöglich zu einem absolut gleichzeitigen zugriff auf dieses critical section, da es noch keine echte multiprozessor arbeit für c++ gibt .... es kann sein das ich hier in der erfahrung hinter dem stand der dinge bin, ich bitte um dringliche korrektur falls dem so ist.
unter vista und windows 2003 server solltest du allerdings beachten das es nicht mehr sicher ist das der besitzer einer CS diese auch freigibt wenn er danach "fast sofort" wieder in sie eintritt, d.h. wenn 2 threads permanent über eine CS laufen, kann es passieren das 1 thread permanent drin rumrödelt, während der andere sich die beine in den bauch steht
-
Ceos schrieb:
selbst bei multicore kommt es mit dem momentanen c++ standard unmöglich zu einem absolut gleichzeitigen zugriff auf dieses critical section, da es noch keine echte multiprozessor arbeit für c++ gibt
Was ist "Multiprozessor Arbeit für C++"?
Ich denke, wenn zwei ASM-Segmente zweier Threads zufällig auf unterschiedlichen Kernen landen, können sie sehr wohl parallel ausgeführt werden. Darauf hat der C++-Compiler an der Stelle auch garkeinen Einfluß mehr.
-
ich meine mal gelesen zu haben das trotz multithread und multicore 2 threads immernoch sequentiell (öhm wie wird das nochmal geschrieben cih steh grad aufm schlau) auf den speicher zugreifen im derzeitigen standard
hm kann auch sein das die meinten das die compilermäßige einflussnahme darauf noch nicht implemntiert ist, dann möcht ich mich für meine schlechte auslegung entschuldigen
-
ich meine mal gelesen zu haben das trotz multithread und multicore 2 threads immernoch sequentiell ...
Das haengt von zu vielen faktoren ab um das so pauschal zu bejahen oder zu verneinen.
Sogar die BS selber verhalten sich z.b. bisserl anders ...wenn du unter windows XP mit normalen compilereinstellungen und keine weiteren API funktionen nutzt als die CreateThread / Resume ... etc, dann werden die threads auf ein und dem selben kern laufen.
Mit compilerdirektiven und einigen extra api aufrufen kann man da auch bisserl nachhelfen.
Ist aber auch logisch, threads untereinander sind eigentlich ziemlich eng verwand, sie teilen sich halt die kompletten ressourcen. Das sind nicht nur die ressourcen die du anlegst, sondern das ganze prozess enviroment. Bei normaler, naiver nutzung der ressourcen von 2 threads auf 2 kernen, wuerden die 2 kerne ihre register und ihre lokalen cashes umherkopieren muessen wie doof. Also performance ade .... Man muss also dazu auch noch andere vorbereitungen treffen das das performancetechnisch geht.Laufen auf 2 kernen realisiert man besser mit multiprozessing als mit multihreading (wenn man nich so tief in die materie einsteigen will). Klar kontorlliertes MT auf 2 kernen kann schon performanter sein als pauschales multiprozessing.
Ciao ...
-
Ceos schrieb:
ich meine mal gelesen zu haben das trotz multithread und multicore 2 threads immernoch sequentiell (öhm wie wird das nochmal geschrieben cih steh grad aufm schlau) auf den speicher zugreifen im derzeitigen standard
Das hängt doch nicht von der Programmiersprache sondern von de jeweiligen Rechnerarchitektur ab. Das mag zum Beispiel bei einem Intel Rechner noch so sein, weil diese noch immer einen FSB haben, aber so ziemlich alle anderen Multiprozessorsysteme machen dies anders. Da gibt es dann parallele Zugriffe auf unterschiedliche Speicherbereiche.
-
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.
