Von Embedded C++ nach Visual C++ MFC: Thread und Prozess-Handling

[Die Wurst (Gast)]

Hallo zusammen,

ich muss gerade ein Stück Embedded Code (C++) auf Visual C++ MFC 
portieren. Nun komme ich aus einer einfach strukturierten Welt und werde 
erschlagen von der Funktionsvielfalt der MFC.

Folgenden bestehenden Sachverhalt aus dem Embedded System mit 
Einfachsbetriebssystem möchte ich abbilden:
mindestens 2 Tasks, ein oder mehrere Auftraggeber-Tasks, ein 
Worker-Task. Der Auftraggeber lastet in einer Queue Aufgaben ein, die 
vom Worker abgearbeitet werden. Der Auftraggeber ist so lange blockiert, 
bis der Worker das Event des Auftraggebers setzt, damit dieser 
weiterlaufen kann.

Auf den PC übertragen sieht das dann so aus:
Die o.g. Funktionalität soll in eine DLL verpackt werden. Die DLL hat 
eine Init + Deinit-Funktion, die einen Worker-Thread 
(AfxBeginThread(...)) startet. Anschließende DLL-Calls stellen die 
Aufträge dar. Eine DLL-Funktion wird also ausgeführt, blockiert bis zur 
Abarbeitung durch den Worker-Thread, und kehrt dann mit dem Ergebnis 
zurück.

- Wie kann ich diesen Sachverhalt in MFC-Bordwerkzeugen umsetzen? Mit 
CEvent?
- Auf dem Embedded System merke ich mir einfach die Task-ID des 
Auftraggebers und lasse ihn auf ein Event warten, dass vom Worker-Task 
gesetzt wird. Die Task-ID muss ich dazu in der Queue mitspeichern, damit 
ich das Event des richtigen Tasks setze. Wie lautet in MFC eine Funktion 
in der Art "GetTaskId()" oder regelt man das über ein CEvent?

Vielen Dank vorab!

[Peter II (Gast)]

Die Wurst schrieb:
> - Auf dem Embedded System merke ich mir einfach die Task-ID des
> Auftraggebers und lasse ihn auf ein Event warten, dass vom Worker-Task
> gesetzt wird. Die Task-ID muss ich dazu in der Queue mitspeichern, damit
> ich das Event des richtigen Tasks setze

jeder Worker braucht sein eigenes Event, dann bauchst du auch nicht die 
ThreadId.

Ich verwende einfach CreateEvent also ohne die MFC funktionen.

[Rufus Τ. F. (rufus)]

Solange Du nicht zwingend MFC verwenden musst, solltest Du das besser 
sein lassen.

Die grundlegenden Dinge, um in einem Win32-Programm mit Threads zu 
arbeiten, stellt die Win32-API zur Verfügung:
CreateThread, CreateEvent/SetEvent, 
WaitForSingleObject/WaitForMultipleObjekt, 
CreateCriticalSection/EnterCriticalSection/LeaveCriticalSection etc.

Mit diesen Funktionen solltest Du zum Ziel kommen.

Im Gegensatz zur MFC-Dokumentation ist die der Win32-API recht 
ausführlich und brauchbar.

[Die Wurst (Gast)]

Peter II schrieb:
> jeder Worker braucht sein eigenes Event, dann bauchst du auch nicht die
> ThreadId.

Ich verstehe das jetzt so, dass das Event selbst weiß, welchem Prozess 
es zugeordnet ist? Also sprich genau der Prozess der sich mit .Lock() 
selbst blockiert hat, teilt vorher dem Worker mit, mit welchem Event er 
später per .Unlock() wieder aufgeweckt werden möchte?

[Peter II (Gast)]

Die Wurst schrieb:
> Ich verstehe das jetzt so, dass das Event selbst weiß, welchem Prozess
> es zugeordnet ist? Also sprich genau der Prozess der sich mit .Lock()
> selbst blockiert hat, teilt vorher dem Worker mit, mit welchem Event er
> später per .Unlock() wieder aufgeweckt werden möchte?

das verstehe ich nicht.

das event selber hat doch die eigenschaft Signalisiert oder nicht. Das 
ganze ist doch Thread Unabhängig.

Was meist du eigentlich mit Prozess? Hast du wirklich mehre Prozesse 
order nur mehre Threads in einem Proczess?

[Die Wurst (Gast)]

Kann sein, dass ich etwas ins Schleudern gerate mit den 
Begrifflichkeiten.
Es handelt sich um eine DLL, die aus anderen Programmen gerufen werden 
kann. Diesen Kontext nenne ich "Prozess". Die DLL Ihrerseits hat einen 
Workerthread, der die anfallenden Aufgaben abarbeitet.

Ich denke der Groschen ist gefallen... ich hab bei CodeProject was 
gefunden:

http://www.codeproject.com/Articles/8211/How-to-use-WIN32-Event-Kernel-Object

Danke für die Hilfe!

[Rufus Τ. F. (rufus)]

Soll diese DLL von mehreren Prozessen gleichzeitig verwendet werden 
und sollen die Threads der DLL prozessübergreifend synchronisiert 
werden?

Dann musst Du prozessübergreifende Synchronisationsobjekte verwenden, 
dafür gibt es die API-Funktionen CreateMutex/OpenMutex/ReleaseMutex. 
Wichtig ist, daß Du einen eindeutigen Namen für das Mutex-Objekt 
verwendest, durch den ist es prozessübergreifend identifizierbar.

[Peter II (Gast)]

Rufus Τ. Firefly schrieb:
> Dann musst Du prozessübergreifende Synchronisationsobjekte verwenden,
> dafür gibt es die API-Funktionen CreateMutex/OpenMutex/ReleaseMutex.
> Wichtig ist, daß Du einen eindeutigen Namen für das Mutex-Objekt
> verwendest, durch den ist es prozessübergreifend identifizierbar.

geht bei CreateEvent genauso

[Rufus Τ. F. (rufus)]

Gewiss, nur ist ein Event ein von einem Mutex grundverschiedenes 
Synchronisationsobjekt. Letzteres wird auch als Semaphore bezeichnet.