Enter/Leave Critical SEction
-
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.
