Ups...
Ich dachte, das ist der "Grundprozess", ich weiß nicht, wie man da sonst sagt...

Auch Prozess ist der falsche Ausdruck. Ein Prozess ist nur ein Container, der den Adressraum usw. für den (Haupt)Thread bereitstellt, der den eigentlichen Code ausführt. Ein Prozess selber führt nie Code aus. Letztendlich läuft es auf einen Handshake hinaus: Der eine Thread sagt dem anderen immer wann er fertig ist und der andere Thread was machen kann. Es geht also immer hin und her wie beim Ping Pong. Dazu hast du drei Threads: den Hauptthread, der die beiden Threads anstößt und die beiden Workerthreads, die letztendlich die Arbeit machen.

Zum Benachrichtigen kann man dann Events nutzen, die sollte es unter .NET auch noch geben oder zu mindes was vergleichbares.

Zitat von Olli:

Sollte gehen, aber was soll das bringen? Im Gegensatz zu Fibers ist das nicht sonderlich gut steuerbar. Am sichersten ist es, wenn sich ein Thread selber schlafenlegt.

Stichwort: Suspend

Abgesehen davon ob es was bringt oder nicht, kann ich den Thread dann ohne Probleme von einem anderem wieder starten?

Sollte, zu mindest geht es unter WinAPI.

Zitat von Speedmaster:

Zitat von Olli:

Sollte gehen, aber was soll das bringen? Im Gegensatz zu Fibers ist das nicht sonderlich gut steuerbar. Am sichersten ist es, wenn sich ein Thread selber schlafenlegt.

Stichwort: Suspend

Abgesehen davon ob es was bringt oder nicht, kann ich den Thread dann ohne Probleme von einem anderem wieder starten?

Ja, ganz einfach mit Resume().

Du kannst von ThreadX ein Control in seinem Thread ansprechen in dem du einen Delegate an seine Invoke methode schickst.
Um thread safety zu wahren gibt es die Monitor klasse (siehe SDK Doku) oder critical sections:

markieren

Code:

lock(someObject)
{
  Statement(someObject);
  someObject.DoSomething();
}

Im allgemein kannst du auch statische Properties als thread safe ansehen solange du in den Accessors nix machst, dass nicht thread safe ist.

Wenn ich DAS mach:

markieren

Code:

lock(typeof(Form1))
{
  Form1.textBox1.Text = Irgendwas;
}

Ist das 1. Zulässig 2. Schön (also gibts ne bessere Möglichkeit) 3. die Form noch Benutzbar, wärend der Thread läuft?

Hi,

zulässig ist es, die Form ist auch weiter benutzbar, allerdings ist es so nicht dazu geeignet, um auf ein Control zuzugreifen.

Ein Zugriff auf ein Control muss immer aus dem Thread erfolgen, der das Control angelegt hat, also (so gut wie immer) aus dem Hauptthread der Anwendung. Das kannst du, wie Robert schon geschrieben hat, erreichen, in dem du die Methode die auf das Control zugreift über Invoke aufrufst.

Beispiel:

markieren

Code:

public class MyThread
{
   
  public delegate void UpdateDelegate(string s);
   
  public TextBox StatusTB;

  void Update(string s)
  {
    StatusTB.Text = s;
  }

  void Execute() // Thread-Routine
  {
    // ...
    StatusTB.Invoke(new UpdateDelegate(Update), new object[] {"foo"});
    // ...
  }

  // ...
}

Das Problem dabei ist, dass der Invoke-Aufruf so lange nicht zurückkehrt bis die übergebene Methode im Hauptthread ausgeführt worden ist und der Thread somit auch nicht weiterarbeiten kann. Sollte das stören, musst du die Daten in einen Zwischenpuffer schreiben (Array oder ähnliches) den Zugriff darauf synchronisieren (manche Collections gibt's schon als Thread-sichere Variante) und dir eine Möglichkeit überlegen, wie du dem Hauptthread mitteilst, dass neue Daten im Puffer sind.

Zu lock:
Das kannst du verwenden, wenn du auf Felder aus verschiedenen Threads heraus zugreifen willst, und verhindern möchtest, dass sie sich dabei in die Quere kommen.

Beispiel:

markieren

Code:

public class GemeinsameDaten
{
  private object dat;

  public object Datum
  {
    set
    {
      lock(this)
      {
        dat = value;
      }
    }
    get
    {
      object d;
      lock(this)
      {
        d = dat;
      }
      return d;
    }
}

Wenn jetzt einer der Threads zum Beispiel set Datum ausführt, wird bei Lock(this) geprüft, ob bereits ein anderer Thread ein lock auf das Objekt ausgeführt hat. Ist das der Fall, dann wartet der neue Thread, bis der andere Thread den kritischen Abschnitt verlassen hat und fährt erst dann fort.

Für asynchrone Aufrufe zwischen den Threads gibt es noch BeginInvoke anstelle des einfachen Invoke.