C# Prozess kein unabhängiger Thread?

[Dirac I. (dirac-impuls)]

Hallo,

ich habe eine Klasse, in der ein Prozess aufgerufen wird, mit dem über 
Stdin und Stdout gequatscht wird.

Wenn ich nun eine Nachricht schicke, etwa

process.StandardInput.WriteLine("ping");

 dann kommt per event nach sehr kurzer Zeit eine Antwort

private void process_OutputDataReceived(object sender, DataReceivedEventArgs e)
{
  Console.WriteLine("Ping erfolgreich");
}

Nun möchte ich aber nach dem abschicken in einer while Schleife auf die 
Antwort warten.

volatile bool pingReceived;
WaitForPing()
{
  pingReceived = false;
  process.StandardInput.WriteLine("ping");
  while(!pingReceived) ;
}

process_OutputDataReceived(object sender, DataReceivedEventArgs e)
{
  pingReceived = true;
}

Allerdings warte ich bis heute auf die Pingantwort. Sehe ich es somit 
richtig, dass ein Process immer ein untergeordneter Thread ist, der nur 
arbeiten darf, wenn der übergeordnete Thread ihn lässt? Da der 
Hauptthread nichts anderes macht, als eine boolsche Variable abzufragen 
find ich es schon ein bisschen schwach, dass mein Prozess keinen 
einzigen Taktzyklus abbekommmt. Habe ich etwas übersehen, kann man da 
noch irgendwo was einstellen?

[Dirac I. (dirac-impuls)]

Ich hätte vielleicht noch dazu schreiben sollen, dass der Debugger 
tatsächlich in der while Schleife stehen bleibt und diese nie verlassen 
wird. Da die Kommunikation zum Process in dem Unterprogramm 
protokolliert wird erkenne ich, dass mit der while Schleife auch 
tatsächlich keine Antwort zurückgeschickt wird während jedoch der "ping" 
Befehl noch erhalten wird. Entferne ich die while Schleife so kommt 
sofort eine Antwort.

Hier nochmal die aktuelle while Schleife:

WaitForPing()
{
  pingReceived = false;
  process.StandardInput.WriteLine("ping");
  while(!pingReceived) ;
  Console.WriteLine("Warum werde ich nie aufgerufen?");
}

[Kaj (Gast)]

Zeig doch einfach den ganzen Code, dann müssen wir nicht erst unsere 
Kristallkugeln rausholen...
Ist pingReceived threadsafe?

Dirac I. schrieb:
> Sehe ich es somit
> richtig, dass ein Process immer ein untergeordneter Thread ist,
Nein. Prozess > Thread
Prozess != Thread
Ein Thread ist ein leichtgewichtiger Unterprozess von einem Prozess. Ein 
Prozess ist aber mit Sicherheit nicht dem Thread untergeordnet.
https://de.wikipedia.org/wiki/Thread_%28Informatik%29#Bedeutungsunterschied_.28Kernel-.29_Thread_gegen.C3.BCber_Prozess.2C_Task_und_User_Thread
https://de.wikipedia.org/wiki/Thread_%28Informatik%29#.NET

Dirac I. schrieb:
> der nur
> arbeiten darf, wenn der übergeordnete Thread ihn lässt?
Wer wann wo wieviel CPU-Zeit bekommt, verwaltet das OS (der Scheduler). 
Deswegen startest du ja einen neuen Prozess/Thread, damit eine aufgabe 
unabhängig vom Rest erledigt werden kann.

Dirac I. schrieb:
> Habe ich etwas übersehen
Mit Sicherheit

Dirac I. schrieb:
> kann man da
> noch irgendwo was einstellen?
Ja, könnte man (Stichwort: Prioritäten), aber das ist nicht das 
Problem, das du hast. Außerdem pfuscht du damit dem Scheduler in die 
Arbeit, und der weiß deutlich besser was er da macht, als du. Wie bei 
Compilern auch.

Ob da wirklich ein neuer Prozess/Thread gestartet wird, kannst du im 
Task-Manager sehen.

[Dirac I. (dirac-impuls)]

Hallo Kaj,

vielen Dank für deine Antwort. Die Threadsicherheit kanns denke ich 
nicht sein, weil der Debugger mir Bescheid geben würde. Alle anderen 
Daten werden immer erfolgreich aus und in den Process hin und her 
geschoben. Auch das Schlüsselwort "volatile" ist hier nicht notwendig.

Das Programm ist einfach zu groß, als dass ich es hier posten könnte 
oder sollte. Es handel sich hierbei um ein kleines Teilproblem eines 
großes Programms. Du hast aber recht, dass ich vergessen habe zu 
erwähnen, dass es sich um eine Windows Forms Awendung handelt.

Ich bin dem Problem jedoch näher gekommen. Der aufgerufene Prozess kann 
beschäftigt oder unbeschäftigt sein, was per Befehl im Stdin/Stdout vom 
oberen C#Programm kommt. In beiden Fällen soll und gibt er eine Antwort 
auf die Pingabfrage.

Prozess unbeschäftigt -> WaitForPing funktioniert immer.
Prozess beschäftigt -> Mit der while Schleife bleibt das Programm 
hängen, ohne while Schleife kommt eine Pingantwort per Event.

Nur wenn die while Schleife vorhanden ist und der Prozess beschäftigt 
ist, bleibt das Programm hängen.


Interessanterweise reicht es nicht aus per Button dem Prozess den Befehl 
zu schicken unbeschäftigt zu sein und direkt dahinter zu pingen. Erst 
wenn ich per ButtonA ihn unbeschäftigt mache und ihn danach per ButtonB 
pinge, kommt er auch mit der while Schleife klar.

[Läubi .. (laeubi)]

Dirac I. schrieb:
> Nun möchte ich aber nach dem abschicken in einer while Schleife auf die
> Antwort warten.

WIeso? Wenn es schon eventbasiert geht kann man das doch nutzen? 
Ansosnten ist beim Busy-Loop immer wenigstens eine kleine Wartezeit 
empfehlenswert um die CPU Last nicht unnötig hoch zu halten.

[Rolf M. (rmagnus)]

Dirac I. schrieb:
> Nun möchte ich aber nach dem abschicken in einer while Schleife auf die
> Antwort warten.

Du willst also die CPU-Last auf 100% treiben, um ein Flag abzufragen? 
Schlechte Idee.

> Habe ich etwas übersehen, kann man da noch irgendwo was einstellen?

Wird die Event-Loop denn überhaupt noch abgearbeitet, wenn dein Programm 
in einer while-Schleife festhängt?

[Dirac I. (dirac-impuls)]

Hallo Läubi,

vielen Dank für deinen Hinweis, es war der richtige.

Läubi .. schrieb:
> WIeso? Wenn es schon eventbasiert geht kann man das doch nutzen?

Weil es nur sehr, sehr selten aufgerufen wird, nur sehr wenig Zeit in 
Anspruch nimmt aber mehrmals im Quellcode benötigt wird.

Ich habe hier übrigens ein sehr interessantes Verhalten festgestellt:

Vorausgesetzt der Prozess arbeitet und es gibt die while Schleife:

Kein Sleep Befehl -> Funktioniert nie
Zu kleiner Sleep Befehl (in meinem Fall bis ca. 50 ms) -> Funktioniert 
nur, wenn Flag-Variable voatile ist
Ausreichend großer Sleep Befehl (in meinem Fall ab ca. 100 ms) -> 
Funktioniert immer, auch wenn die Flag-Variable nicht volatile ist.

[Dirac I. (dirac-impuls)]

> Wird die Event-Loop denn überhaupt noch abgearbeitet, wenn dein Programm
> in einer while-Schleife festhängt?

Nein. Aber jetzt geht es. Vielen Dank auch an dich!