Thread performance



  • Hallo, ich habe einmal eine Frage zu Threads.

    Wenn ich einen Thread mit "sleep" schlafen lege, bedeutet das dann, dass der Thread im Schlafzustand überhaupt keine Rechenleistung des Systems beansprucht?

    Der Hintergrund:
    Ich habe mir zwei worker threads erzeugt, die in einer endlosschleife laufen und mit einer ihnen zugewiesenen abtastrate eine shared memory abtasten. Sind sie mit ihrer Aufgabe schneller fertig, schlafen sie den rest der zeit. Ich frage mich nun, ob es vielleicht bessere Ansätze gibt oder ich irgendetwas übersehen habe, was das thema thread programmierung und perfomanz angeht.

    Ach ja eine Frage fällt mir da auch noch ein. Gibt es eine sleep funktion außerhalb von boost, die es mir erlaubt ms oder ns zu schlafen? (Ich programmiere unter Suse Linux)

    Danke für eure Hilfestellung.

    Lg
    Gundis



  • Gundis schrieb:

    Wenn ich einen Thread mit "sleep" schlafen lege, bedeutet das dann, dass der Thread im Schlafzustand überhaupt keine Rechenleistung des Systems beansprucht?

    Das ist die Idee, ja.

    Gundis schrieb:

    Der Hintergrund:
    Ich habe mir zwei worker threads erzeugt, die in einer endlosschleife laufen und mit einer ihnen zugewiesenen abtastrate eine shared memory abtasten. Sind sie mit ihrer Aufgabe schneller fertig, schlafen sie den rest der zeit. Ich frage mich nun, ob es vielleicht bessere Ansätze gibt oder ich irgendetwas übersehen habe, was das thema thread programmierung und perfomanz angeht.

    Ich kenne mich mit "shared memory" (falls Du damit Interprozesskommunikation über gemeinsamen Speicher meinst) nicht aus.

    Für das Synchronisieren von Threads innerhalb desselben Prozesses werden üblicherweise "mutexes" verwendet. "Mutexes", "Locks" und "Condition variables" sind Bausteine einer modernen Threading-Bibliothek. Das "Hello World!" der Thread-Programmierung ist wohl das Consumer/Producer-Beispiel. Ein Thread produziert Daten und ein anderer will diese Verarbeiten. Das kann man zB über eine Queue lösen, wobei der Zugriff auf die Queue synchronisiert wird. Es gibt sowohl für den "Producer" als auch den "Consumer" eine Bedingung, auf die gewartet werden muss. Der Producer wartet eventuell darauf, dass es in der die Queue wieder freie Plätze gibt ("not_full") und der Consumer wartet eventuell auf Daten in der Queue ("not_empty").

    Mit Boost.Thread würde das in etwa so aussehen:

    // Gemeinsames
    boost::mutex mein_mutex;
    boost::condition_variable not_full;
    boost::condition_variable not_empty;
    std::queue<int> queue;
    typedef boost::lock_guard<boost::mutex> mein_lockguard_t;
    cosnt int maxqueue = 10;
    
    // Producer
    for (;;) {
      int z = ...etwas.berechnen...;
      {
        mein_lockguard_t lck (mein_mutex);
        while (queue.size()>=maxqueue) not_full.wait(lck);
        queue.push_back(z);
        if (queue.size()==1) not_empty.notify_all();
      } // <-- mutext wird im destrucor von lock_guard freigegeben
    }
    
    // Consumer
    for (;;) {
      int z;
      {
        mein_lockguard_t lck (mein_mutex);
        while (queue.empty()) not_empty.wait(lck);
        z = queue.front();
        queue.pop_front();
        if (queue.size()==maxqueue-1) not_full.notify_all();
      } // <-- mutext wird im destrucor von lock_guard freigegeben
      ...mit.z.etwas.anstellen...
    }
    

    Alle Angaben ohne Gewähr. 😉


Log in to reply