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é

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.

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.

Gemeinsam genutzte ressourcen muss man locken, die frage ist eigentlich, sind gemeinsam genutzte ressourcen immer notwendig ?

wobei rein lesende zugriffe schon parrallel gehen ...

Ciao ...

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...

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

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.

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 ...

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.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.