mikrocontroller.net

Forum: PC-Programmierung Multithreading unter WinCE


Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,


ich hänge hier gerade an einer konzeptionellen Überlegung. Für eine 
Maschinensteuerung (Windows CE 5.0) soll ein Prozess (erstellt mit 
EVC++4.0) in mehrere Threads aufgeteilt werden. Der Prozess ist eine 
reine "Konsolenanwendung", d.h. hat keine Bedienoberfläche, sondern 
kommuniziert vie TCP mit einer anderen Anwendung.

Nun möchte ich im groben folgendes realisieren:
- Ein Thread kümmert sich um die TCP-Kommunikation, d.h. wartet auf eine 
Verbindung vom entfernten Programm und tauscht nach Verbindungsaufbau 
zyklisch Steuerdaten aus
- Ein Thread realisiert eine/mehrere Schrittketten für die 
Ablaufsteuerung an der Maschine

Somit existiert zu jeder "Funktionalität" nur genau ein Thread mit 
völlig unterschiedlicher Struktur. Die Threads sollen zur 
Ablaufkoordination lediglich beide Zugriff auf ein globales Struct 
haben.

Nun meine Überlegungen:
- Da die Boost-Libs meiner Recherche nach nicht unter CE laufen, würde 
ich die Threads mit den WIN32-C-Funktionen realisieren:
http://msdn.microsoft.com/en-us/library/y6h8hye8.aspx
- In die Struct, auf die beide Threads Zugriff erhalten sollen, würde 
ich ein CMutex einbauen und vor jedem Zugriff locken

Meine Fragen:
- Ist das prinzipiell ein brauchbares Konzept, oder ist da ein grober 
Denkfehler drin?
- Sehe ich das richtig, dass ich für wirklich alle Funktionen, die ich 
aus BEIDEN Threads aufrufe, sicherstellen muss, dass diese 
Multithreading-Safe sind? Die C-Standard-Library und die WIN32-API 
sollten doch prinzipiell sicher sein, wenn ich _beginthread() an Stelle 
von CreateProcess() verwende?
- Kann ich innerhalb jedes Threads weiterhin wie gewohnt mit new/delete 
Objekte erzeugen, ohne dass ich diese separat schützen muss (kein 
gemeinsamer Zugriff)
- Muss ich die Threads noch irgendwie voreinander schützen?

Ich würde mich freuen, wenn ich ein paar Kommentare zu obigen Zeilen 
bekommen könnte, um sicherzugehen, dass das Konzept halbwegs passt.

Peter

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> - Ist das prinzipiell ein brauchbares Konzept, oder ist da ein grober
> Denkfehler drin?

Das sollte so schon gehen.

> - Sehe ich das richtig, dass ich für wirklich alle Funktionen,
> die ich aus BEIDEN Threads aufrufe, sicherstellen muss, dass diese
> Multithreading-Safe sind? Die C-Standard-Library und die WIN32-API
> sollten doch prinzipiell sicher sein, wenn ich _beginthread() an
> Stelle von CreateProcess() verwende?

Du meinst vermutlich "an Stelle von CreateThread()". Aber auch das wird 
überbewertet. Sofern man nicht die ganz perversen C-Funktionen 
verwendet, die interne Statusvariablen nutzen (strtok ist wohl ein 
Kandidat), kann man auch ohne Probleme CreateThread verwenden. Ich mache 
das unter NT (2K/XP/2K3) seit 15 Jahren in auch ziemlich großen Systemen 
so, ohne auch nur ein einziges Mal ein _beginthread-Problem gehabt zu 
haben.

> - Kann ich innerhalb jedes Threads weiterhin wie gewohnt mit
> new/delete Objekte erzeugen, ohne dass ich diese separat
> schützen muss (kein gemeinsamer Zugriff)

Aber ja doch, sofern Du mit der geeigneten Multithreaded-Runtimelibrary 
linkst.

- Muss ich die Threads noch irgendwie voreinander schützen?

Nö, sofern Du Zugriffe auf gemeinsam genutzte Dinge mit "critical 
sections" oder anderen Synchronisationsobjekten schützt und ansonsten 
Threads mit Events o.ä. aufeinander warten lässt, ist alles wesentliche 
getan.
Da der C-Compiler selbst nichts von Multithreading weiß, ist es 
sinnvoll, von mehreren Threads gemeinsam genutzte Variablen als 
volatile zu deklarieren, genau so, wie man es auch bei Nutzung von 
Interruptcode machen würde.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rufus,

vielen Dank für deine schnelle und verständliche Antwort!


> > - Kann ich innerhalb jedes Threads weiterhin wie gewohnt mit
> > new/delete Objekte erzeugen, ohne dass ich diese separat
> > schützen muss (kein gemeinsamer Zugriff)
>
> Aber ja doch, sofern Du mit der geeigneten Multithreaded-Runtimelibrary
> linkst.

Das ist mir nicht ganz klar, new und delete gehören doch zum 
Sprachumfang von C++. Gegen welche Runtimelibrarys linke ich denn da? 
Ich vermute irgendwelche Systemaufrufe.
Aber bei einem Multitaskingfühigen SDK sollte doch alles passen?!


> Da der C-Compiler selbst nichts von Multithreading weiß, ist es
> sinnvoll, von mehreren Threads gemeinsam genutzte Variablen als
> volatile zu deklarieren, genau so, wie man es auch bei Nutzung von
> Interruptcode machen würde.
Das habe ich noch nirgends gelesen, danke für den Tipp!

Peter

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das ist mir nicht ganz klar, new und delete gehören doch zum
> Sprachumfang von C++. Gegen welche Runtimelibrarys linke ich denn da?

Na, die, in denen die Implementierung der C/C++-Standardfunktionen 
enthalten ist. Sieh Dir einfach mal den Inhalt des 
Library-Verzeichnisses Deines Compilers an, da wirst Du mehrere 
Libraries mit fast gleichem Namen finden.

Bei VC6 für Win32 beispielsweise ist ein angehängtes "mt" der Hinweis 
auf die Multithreading-Variante, ein angehängtes "d" steht für die 
Debugversion etc.

Das wird bei EVC++ nicht sehr anders aussehen. Du musst Dich 
glücklicherweise nicht damit auseinandersetzen, denn die IDE bietet 
Einstellmöglichkeiten, ob single- oder multithreading-Code erzeugt 
werden soll. Und das entscheidet dann unter anderem auch, welche Library 
verwendet wird.

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly wrote:
> Du meinst vermutlich "an Stelle von CreateThread()". Aber auch das wird
> überbewertet. Sofern man nicht die ganz perversen C-Funktionen
> verwendet, die interne Statusvariablen nutzen (strtok ist wohl ein

Man kann es meiner Meinung nach nicht laut genug sagen: Finger weg von 
CreateThread!

Man muss schon ganz genau wissen was man macht, wenn man auf 
CreateThread setzt. Ich vermute mal, dass Du in Deinem "großen" Systen 
gegen die DLL-Version der CRT linkst. Hier ist es natürlich kein 
Problem, da die DLL eventuell fehlende per-thread-data in DllMain bei 
DLL_THREAD_ATTACH nachträglich allokieren kann und das bei Bedarf auch 
macht. Problematisch wird es aber in kleineren Progrämmchen, die 
statisch linken (und dann wird auch ein DisableThreadLibraryCalls zum 
Abenteuer). Und Peter wird ziemlich sicher statisch linken...

Und so "pervers" müssen die Funktionen gar nicht sein. Schließlich ist 
auch alles das betroffen, was in irgendeiner Art und Weise 
locale-sensitive ist.

Peter, bitte verwende auf alle Fälle _beginthreadex, denn damit 
funktioniert es immer. Alles andere ist viel zu unsicher.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich vermute mal, dass Du in Deinem "großen" Systen
> gegen die DLL-Version der CRT linkst.

Nein, ich linke statisch.
Interessieren würde mich ein Beleg, der tatsächlich zeigt, daß 
CreateThread Probleme verursacht, nicht nur Zitate von Warnungen in der 
Dokumentationen und allgemeinen Annahmen. Wäre ja schon interessant, zu 
sehen, warum es auch funktionieren kann.

Wer hat eigentlich diese merkwürdige Formulierung "gegen etwas linken" 
erfunden?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für eure weiteren Beiträge (und Bedenken)!

> Du musst Dich glücklicherweise nicht damit auseinandersetzen,
> denn die IDE bietet Einstellmöglichkeiten, ob single- oder
> multithreading-Code erzeugt werden soll.
Hm, hab grade mal sämtliche Compiler/Linkeroptionen in einem 
VS2008-Projekt überflogen, und keinen derartigen Schalter gesehen. Oder 
macht das der Compiler automatisch?

> Und Peter wird ziemlich sicher statisch linken...
Jein, sowohl statisch als auch DLLs die erst zur Laufzeit geladen werden 
(über getprocaddress()). Verstehe ich dich richtig, das das unkritisch 
sein sollte? Erstellt eine DLL für jeden Prozess oder sogar für jeden 
Thread einen eigenen Stack/Heap? Kann ich eine DLL überhaupt mehrfach 
(also für jeden Thread) innerhalb eines Prozesses laden? Oder muss ich 
die Funktionen global bereitstellen?
Also wäre das ja ein Grund, gemeinsam genutzte Funktionen in eine DLL 
auszulagern, auch wenn das gar nicht nötig wäre.

> Peter, bitte verwende auf alle Fälle _beginthreadex, denn damit
> funktioniert es immer. Alles andere ist viel zu unsicher.
Gern, spricht meiner bisherigen Recherche nach ja auch nichts dagegen

> Wer hat eigentlich diese merkwürdige Formulierung "gegen etwas linken"
> erfunden?
Vermutlich ein Rechter mit Grammatikschwäche ;-)

Peter

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly wrote:
> Interessieren würde mich ein Beleg, der tatsächlich zeigt, daß
> CreateThread Probleme verursacht, nicht nur Zitate von Warnungen in der

Nun, intern werden nun mal auf den Thread bezogene Daten gehalten. Diese 
Daten müssen irgendwo gespeichert werden. Rufst Du eine perverse 
Funktion auf, z.B. isspace (locale-sensitive), wird der Platz für diese 
Daten allokiert, so es nicht bereits geschehen ist. Soweit ist das also 
kein Problem.

Wenn Du nun den Thread in Deiner statischen Variante enden lässt, ist da 
niemand, der den Platz für diese Daten wieder freigibt. Solche Lecks 
sind in meinen Augen schon ein Problem, unabhängig der Aussagen der 
Marketings.

Nimmst Du hingegen _beginthreadex, passiert das Freigeben automatisch: 
Kein Leck, kein Problem (solange man die Finger von der ebenfalls 
"verbotenen" Funktion ExitThread lässt).

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter wrote:
>> Du musst Dich glücklicherweise nicht damit auseinandersetzen,
>> denn die IDE bietet Einstellmöglichkeiten, ob single- oder
>> multithreading-Code erzeugt werden soll.
> Hm, hab grade mal sämtliche Compiler/Linkeroptionen in einem
> VS2008-Projekt überflogen, und keinen derartigen Schalter gesehen. Oder
> macht das der Compiler automatisch?

Rufus meint das, was Du unter Konfigurationseigenschaften -> C++ -> 
Codegenerierung -> Laufzeitbiliothek findest. Und nein, hier man man 
nicht (mehr) auf single-threaded umstellen. Das war zu Zeiten des VC6 
noch anders. Mit Deinem VS2008 hingegen bist Du hier immer auf der 
sicheren Seite.

> Jein, sowohl statisch als auch DLLs die erst zur Laufzeit geladen werden
> (über getprocaddress()). Verstehe ich dich richtig, das das unkritisch
> sein sollte? Erstellt eine DLL für jeden Prozess oder sogar für jeden
> Thread einen eigenen Stack/Heap? Kann ich eine DLL überhaupt mehrfach

Der Stack liegt in der Hand des Threads. Das ist also immer der selbe, 
egal ob DLL oder EXE. Beim Heap sieht das aber anders aus:

- Linkst Du ein Modul (EXE oder DLL) gegen die statische Version der 
CRT, benutzt diese Modul auch einen eigenen Heap. Das free muss demnach 
dort passieren, wo das malloc passiert ist. Modul A kann den von Modul B 
angeforderten Speicher nicht freigeben.

- Linkst Du gegen die DLL-Version der CRT, passiert das malloc und free 
automatisch an der richtigen Stelle. Hier kannst Du Speicher von Modul A 
in Modul B freigeben.

- Sind Modul A und Modul B gegen die DLL-Version der CRT gelinkt, dies 
aber in unterschiedlichen Versionen (z.B. EXE mit dem VS2008, DLL noch 
auf dem Stand VC6), musst Du mit den Freigaben natürlich wieder 
aufpassen.

Am Besten ist es aber, sich auf nichts und niemanden zu verlassen. Das 
Modul, das Speicher anfordert, gibt diesen wieder frei, niemand anders.

> (also für jeden Thread) innerhalb eines Prozesses laden? Oder muss ich
> die Funktionen global bereitstellen?
> Also wäre das ja ein Grund, gemeinsam genutzte Funktionen in eine DLL
> auszulagern, auch wenn das gar nicht nötig wäre.

Eine DLL wird nicht in einen Thread geladen, sondern in den Adressraum 
des Prozesses. Wenn Du die DLL erst einmal geladen hast, können alle 
Threads des Prozesses auf deren Funktionen nach belieben eindreschen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.