Ich experimentiere gerade mit Parallelisierung herum. Ich habe einen Threadpool geschrieben und versuch, damit einen Akkumulierungsalgorithmus zu parallelisieren. Leider funktioniert das ganze manchmal und manchmal nicht, d.h. manchmal stürzt das Programm ab. Ich frage mich, ob das ein Bug in gcc 4.7 sein könnte. Mir ist nicht bewusst, etwas falsch zu machen. Es würde mich freuen, wenn mal jemand einen Blick auf den Code werfen könnte (ist kompilierbar). Danke

#include <thread>
#include <condition_variable>
#include <mutex>
#include <vector>
#include <queue>
#include <functional>
#include <iostream>

class task
{
    bool done;
    std::mutex mutex;
    std::condition_variable cond;
    std::function<void()> func;
public:
    template<class F,  class ...Args>
    task(const F& f, Args ...args):
        done(false),
        func(std::bind(f, args...))
    {
    }

    void run()
    {
        func();
        set_done();
    }

    void set_done()
    {
        std::lock_guard<std::mutex> lock(mutex);

        done = true;
        cond.notify_all();
    }

    void wait()
    {
        std::unique_lock<std::mutex> lock(mutex);

        while(!done)
        {
            cond.wait(lock);
        }
    }
};

class thread_pool
{
    bool m_quit;
    int m_num;
    int m_idle;

    std::vector<std::thread> m_threads;
    std::queue<task*> m_queue;

    mutable std::mutex m_mutex;
    std::condition_variable m_cond;

    void worker()
    {
        while(1)
        {
            std::unique_lock<std::mutex> lock(m_mutex);

            ++m_idle;

            while(!m_quit && m_queue.empty())
            {
                m_cond.wait(lock); // wait for quit signal or data in queue
            }

            if(m_quit) return;

            task* t = m_queue.front();
            m_queue.pop();
            --m_idle;
            lock.unlock();

            t->run();
        }
    }

public:
    thread_pool(int num_threads):
        m_quit(false),
        m_num(num_threads),
        m_idle(0)
    {
        std::lock_guard<std::mutex> lock(m_mutex);

        for(int i = 0; i < m_num; ++i)
        {
            m_threads.emplace_back(std::thread(&thread_pool::worker, this));
        }
    }

    ~thread_pool()
    {
        std::unique_lock<std::mutex> lock(m_mutex);
        m_quit = true;
        m_cond.notify_all();
        lock.unlock();

        for(auto &i: m_threads) i.join();
    }

    void schedule(task& t)
    {
        std::unique_lock<std::mutex> lock(m_mutex);

        m_queue.push(&t);
        m_cond.notify_all();
    }

    void run(task& t)
    {
        std::unique_lock<std::mutex> lock(m_mutex);

        if(m_idle < 1)
        {
            lock.unlock();
            t.run();
        }
        else
        {
            m_queue.push(&t);
            m_cond.notify_all();
        }
    }

    bool try_run(task& t)
    {
        std::unique_lock<std::mutex> lock(m_mutex);

        if(m_idle < 1)
        {
            return false;
        }
        else
        {
            m_queue.push(&t);
            m_cond.notify_all();
        }
    }

    int num_idle() const
    {
        std::lock_guard<std::mutex> lock(m_mutex);

        return m_idle;
    }
};

template<class Iter, class T>
void accumulate(Iter start, Iter end, T& val, thread_pool& tp)
{
    if(start == end) return;

    if(std::distance(start, end) == 1)
    {
        val = *start;
        std::this_thread::sleep_for(std::chrono::milliseconds(100));
        return;
    }

    if(std::distance(start, end) == 2)
    {
        val = 0;
        val += *start++;
        val += *start;
        std::this_thread::sleep_for(std::chrono::milliseconds(200));
        return;
    }

    Iter mid = start;
    std::advance(mid, std::distance(start, end) / 2);

    T a = 0, b = 0;

    task t(accumulate<Iter, T>, start, mid, std::ref(a), std::ref(tp));
    tp.run(t);
    accumulate(mid, end, b, tp);
    t.wait();

    val = a + b;
}

int main()
{
    thread_pool tp(8);
    std::vector<int> v(100, 1);
    int sum = 0;
    accumulate(v.begin(), v.end(), sum, tp);
    std::cout << sum;

    return 0;
}

Leider funktioniert das ganze manchmal und manchmal nicht, d.h. manchmal stürzt das Programm ab.

Ja, genau das passiert, wenn man bei mehreren Threads was falsch macht.

Ich frage mich, ob das ein Bug in gcc 4.7 sein könnte.

Sehr unwahrscheinlich.

Mir ist nicht bewusst, etwas falsch zu machen. Es würde mich freuen, wenn mal jemand einen Blick auf den Code werfen könnte (ist kompilierbar). Danke

Geh mal davon aus, dass du was falsch gemacht hast und verwende einen Debugger.

Fehlermeldung? Was sagt der Debugger/Stacktrace?

Windows sagt "test.exe funktioniert nicht mehr"

Wie könnte man da mit einem Debugger ansetzten? Mir kommt langsam die Vermutung dass da irgendwo noch Memorybarrieren rein müssen.

threading ist die hölle

Ein gutes Programm sollte aber alle CPU-Kerne optimal nutzen. Nur so werden Programme heutzutage noch schneller.

Wie könnte man da mit einem Debugger ansetzten?

So wie sonst auch...

lol warum sind da sleep aufrufe drin

Das ist nur zum testen ob man überhaupt einen Geschwindigkeitszuwachs durch Parallelisierung sieht. Das macht die Zeitmessung einfacher.

Das ist nur zum testen ob man überhaupt einen Geschwindigkeitszuwachs durch Parallelisierung sieht. Das macht die Zeitmessung einfacher.

Und verfälscht das Ergebnis extremst. Ob du Aufgaben parallelisierst die jeweils 2-3 Prozessortakte brauchen (die Addition) oder Aufgaben, die 200ms brauchen (sleep) ist ein gewaltiger Unterschied.

P.S.: Eine wesentlich bessere Strategie wäre hier übrigens, den Bereich in num_threads Teile aufzuteilen, die dann von den einzelnen Threads komplett bearbeitet werden. Das Aufteilen bis hinunter zu 1 oder 2 Elementen bringt hingegen massiven Overhead und dürfte deutlich(!) langsamer sein als eine Lösung mit nur einem Thread. Selbst die Aufteilung in mehrere Bereiche bringt nur etwas, wenn jeder Einzelbereich sehr groß ist, so dass der Taskoverhead klein gegenüber der Dauer der Aufgabe ist.

Ein gutes Programm sollte aber alle CPU-Kerne optimal nutzen. Nur so werden Programme heutzutage noch schneller.

Wenn man weiß was man tut, auf single core schon alles rausgeholt hat und das Problem überhaupt parallelisierbar ist, dann ja.

Stefan schrieb:

Das ist nur zum testen ob man überhaupt einen Geschwindigkeitszuwachs durch Parallelisierung sieht. Das macht die Zeitmessung einfacher.

Und verfälscht das Ergebnis extremst. Ob du Aufgaben parallelisierst die jeweils 2-3 Prozessortakte brauchen (die Addition) oder Aufgaben, die 200ms brauchen (sleep) ist ein gewaltiger Unterschied.

Dann nimm von mir aus an, dass hier riesige Matrizen addiert werden.
Wenn das Programm nicht crasht, sieht man sehr schön wie die Laufzeit mit der Anzahl Threads skaliert. Es geht hier mehr darum ein Konzept zu prüfen.

Stefan schrieb:

Ein gutes Programm sollte aber alle CPU-Kerne optimal nutzen. Nur so werden Programme heutzutage noch schneller.

Wenn man weiß was man tut, auf single core schon alles rausgeholt hat und das Problem überhaupt parallelisierbar ist, dann ja.

Und wenn man dann noch lock-free programmiert.

sleep ist wohl die dümmste Idee um Parallelisierung zu messen. Da sind nämlich 100 Threads auf 1 CPU sogar schneller als 1 overheadfreier Thread auf 1 CPU.

Noch dazu ist der Code von __Stefan__ viel zu lov-level angesetzt. Richtige Parallelisierung erreicht man über Rekursion und mit std::future, denn ein parallelisiertes Programm, das manchmal abstürzt und deadlocks provoziert ist schlechter als ein korrektes unparallelisiertes.

otze schrieb:

Stefan schrieb:

Ein gutes Programm sollte aber alle CPU-Kerne optimal nutzen. Nur so werden Programme heutzutage noch schneller.

Wenn man weiß was man tut, auf single core schon alles rausgeholt hat und das Problem überhaupt parallelisierbar ist, dann ja.

Und wenn man dann noch lock-free programmiert.

sleep ist wohl die dümmste Idee um Parallelisierung zu messen. Da sind nämlich 100 Threads auf 1 CPU sogar schneller als 1 overheadfreier Thread auf 1 CPU.

Noch dazu ist der Code von __Stefan__ viel zu lov-level angesetzt. Richtige Parallelisierung erreicht man über Rekursion und mit std::future, denn ein parallelisiertes Programm, das manchmal abstürzt und deadlocks provoziert ist schlechter als ein korrektes unparallelisiertes.

Wie wäre es mit ein Bisschen konstruktiver Kritik an meinem Code, anstatt sinnleerem gemotze? Hast du konkrete Änderungsvorschläge für die task- und thread_pool klasse, die die Stabilität verbessern könnten?

Dann nimm von mir aus an, dass hier riesige Matrizen addiert werden.

Dann linkste lieber die OpenMP-Version von ATLAS anstatt das selbst zusammenzustümpern.

Wenn man weiß was man tut, auf single core schon alles rausgeholt hat und das Problem überhaupt parallelisierbar ist, dann ja.

Das Problem, das er hier lösen möchte (große Mengen an Zahlen akkumulieren) ist sogar "embarrassingly parallel". Sicherlich gibt es dafür (angefangen vom kleinen Gauß für 1 bis n) andere Methoden, aber er schreibt doch, dass er rumspielt und lernen möchte. Was sollen also diese ganzen demotivierenden Beiträge?

Niemand schreibt, dass der resultierenden Code produktiv eingesetzt werden soll. Von daher sind jegliche Argumente die aufs Ersparen von (Arbeits-/Lern-)Aufwand hinauslaufen unbedeutend. Wenn er etwas lernen will, muss er eben einen gewissen Aufwand betreiben.

Stefan, du solltest mal überprüfen, weshalb dein Programm abstürzt.

Valgrind (auch mit --tool=helgrind und --tool=drd) ist hierbei sehr hilfreich, gibt es aber glaube ich nicht für Windows. Notfalls mal in einer Linux-VM ausprobieren. Hast du eventuell einen GCC 4.8 zur Verfügung? Damit könntest du dein Programm auch mit ThreadSanitizer und/oder AddressSanitizer kompilieren. Beim ersteren handelt es sich um einen bei Google entwickelten Datarace-Detektor. Weiß aber auch nicht, ob die unter Windows funktionieren. Unter Linux wird ein x86-64-System benötigt.

Das sind so die einfachen Ansätze, die dir schnelle Ergebnisse bringen, mit bedeutend weniger Aufwand als bei einem General-Purpose-Debugger wie GDB oder dem Microsoft-Debugger nötig wäre.

Ansonsten kann ich dir zum Lernen für einen Überblick das Perfbook ("Is Parallel Programming Hard, And, If So, What Can You Do About It?) empfehlen. Gibt es hier kostenlos. Ansonsten die üblichen Bücher über Betriebssysteme und Synchronisationsprobleme. Vorsicht bei Beispielcode von irgendwelchen Websites. In diesem Bereich ist der öfter falsch als richtig. "Es funktioniert" ist in der nebenläufigen Programmierung noch weniger ein Zeichen für Korrektheit als bei C und C++ ohnehin schon.

Wenn alles nichts hilft und du nicht weiterkommst, mach eine Pause und guck dir deinen Code danach nochmal in Ruhe an und denke jede Möglichkeit durch. Was anderes wird dir oft nicht bleiben. Dazu musst du natürlich erstmal wissen was zu erwarten ist.

warum löst den jetzt nicht endlich jemand die fehler in seinem konkreten code wenn multithreading doch angeblich so einfach ist

Weil es eben vermutlich doch nicht so einfach ist, und vor allem mit viel Arbeit verbunden.

@TE: Ich kann dir das Buch C++ Concurrency in Action empfehlen, in dem auf genau solche Aufgabenstellungen wie deine eingegangen wird. Die Erklaerungen sind sehr ausfuehrlich.

Ansonsten hab ich gerade nicht die Zeit, mir dein Problem genauer anzusehen.

Angenommen, es laufen 8 Threads, wie wird sichergestellt, dass nur einer gleichzeitig diese Variable veraendert (jaja, ints etc. sollen ja atomic sein). Angenommen val ist kein int ...

if(std::distance(start, end) == 1) 
    { 
        val = *start; 
        std::this_thread::sleep_for(std::chrono::milliseconds(100)); 
        return; 
    }

Warum nicht einfach futures benutzen anstatt seine eigene Threadklassen zu basteln?

Ich hatte eben gedacht, ich kann das auch
Jetzt verwende ich ja packaged_task zusammen mit future. Es erfordert etwas mehr Tipparbeit bei der Verwendung, aber zumindest läuft es sauber.

aber zumindest läuft es sauber.

Nein, tut es nicht, weil du mit sum einen shared state hast, dessen Zugriff nicht synchronisiert ist (eigentlich).

Warum nicht einfach futures benutzen anstatt seine eigene Threadklassen zu basteln?

Angenommen, es laufen 8 Threads, wie wird sichergestellt, dass nur einer gleichzeitig diese Variable veraendert (jaja, ints etc. sollen ja atomic sein). Angenommen val ist kein int ...

if(std::distance(start, end) == 1) 
    { 
        val = *start; 
        std::this_thread::sleep_for(std::chrono::milliseconds(100)); 
        return; 
    }

Ich habs mal kommentiert. Ansonsten bitte nicht den Sinn des Algos hinterfragen.

template<class Iter, class T> 
void accumulate(Iter start, Iter end, T& val, thread_pool& tp) 
{ 
    if(start == end) return; 

    if(std::distance(start, end) == 1) 
    { 
        val = *start; 
        std::this_thread::sleep_for(std::chrono::milliseconds(100)); 
        return; 
    } 

    if(std::distance(start, end) == 2) 
    { 
        val = 0; 
        val += *start++; 
        val += *start; 
        std::this_thread::sleep_for(std::chrono::milliseconds(200)); 
        return; 
    } 

    Iter mid = start; 
    std::advance(mid, std::distance(start, end) / 2); 

// Temporäre objekte für rekursive Aufrufe
    T a = 0, b = 0; 
// range wird in zwei Teile geteilt, rekursiver Aufruf von accumulate für beide
// Teile.
// rekursiver Aufruf 1. Hälfte von Range. Threaded wenn thread verfügbar.
    task t(accumulate<Iter, T>, start, mid, std::ref(a), std::ref(tp)); 
    tp.run(t); 
// rekursiver Aufruf 2. Hälfte von Range.
    accumulate(mid, end, b, tp); 

    t.wait(); 

    val = a + b; 
}

Es erfordert etwas mehr Tipparbeit bei der Verwendung

Nicht bei mir. So haette ich es gemacht (quick and dirty), keine extra Klassen fuer Task, Threadpool etc:

#include <algorithm>
#include <numeric>
#include <thread>
#include <future>
#include <iostream>
#include <vector>
#include <chrono>

template<typename T>
int acc(T start, T end)
{
    int sum = 0;
    for(auto it = start; it != end; ++it)
    {
        sum += *it;
        std::this_thread::sleep_for(std::chrono::milliseconds(100));
    }
    return sum;

    //return std::accumulate(start, end, 0);
}

template<typename T>
int para_acc(T start, T end, int split_count)
{
    //return acc(start, end);
    if (split_count != 0)
    {
        auto mid = start + std::distance(start, end)/2;
        auto v1 = std::async(para_acc<T>, start, mid, split_count-1);
        auto v2 = std::async(para_acc<T>, mid, end, split_count-1);
        return v1.get() + v2.get();
    }
    else
        return acc(start, end);
}

int _tmain(int argc, _TCHAR* argv[])
{
    std::vector<int> vec(100,1);
    std::cerr << para_acc(vec.begin(), vec.end(), 3) << '\n';
    return 0;
}

// Temporäre objekte für rekursive Aufrufe 
    T a = 0, b = 0;

Diese Zeile habe ich wohl uebersehen.

Weshalb verwendest du überhaupt Rekursion? Du gibst ja die die Threadanzahl durch split_count direkt vor: n = 2^split_count.
Ausserdem erzugst du so Threads, die nichts machen ausser zu warten, abgesehen davon dass Threaderzeugung einen Overhead hat, den man mit Pools vermeiden kann.

Ich will 1 Thread pro CPU-Kern haben, nicht mehr, und die sollen immer schön gefüttert werden.

Dann musst du bedenken, dass die Abarbeitung eines sub-ranges schneller gehen kann als die eines anderen, das heisst Workerthreads können frei werden, während der Algo läuft. Der Algorithmus soll den frei werdenden Worker an anderer Stelle verwenden können.

Wenn man async verwendet, sollte man das so machen, ansonsten geht die Parallelität möglicherweise flöten:

std::async(std::launch::async, ...);

Übrigens läuft dein Algo nur mit random access Iteratoren.