2009-03-12 8 views
5

Ich arbeite derzeit an einer Multi-Thread-Anwendung, die auf Arm-und PPC-Architektur eingesetzt werden würde. Ich habe ein Problem mit pthread_cancel am Arm.pthread_cancel verhält sich auf arm und ppc anders?

pthread_cancel auf Arm verhält sich nicht gleich mit ppc. Der Thread wird abgebrochen, aber der Destruktor für die lokale Variable des Threads wird nicht am Arm aufgerufen. Ich habe auch versucht, eine Stornierungsbereinigungshandlerroutine zu definieren, die über pthread_cleanup_push installiert wurde. Aber es wird nicht aufgerufen, wenn der Thread abgebrochen wird.

Der Code funktioniert gut mit ppc. Wenn ein Thread abgebrochen wird, wird der Destruktor der lokalen Variablen aufgerufen. Und als ich explizit einen Bereinigungs-Handler definiert habe, wurde er aufgerufen und ausgeführt, als pthread_cancel aufgerufen wurde.

Fehle ich etwas? Einige Compiler-Optionen vielleicht?

  • Programmiersprache: C++
  • Compiler: arm-linux-g ++/powerpc-linux-g ++
  • OS: Linux

EDIT:

Ich habe eine Art gefunden ähnliches Problem angemeldet libc bug.

Mit gcc anstelle von g ++ und Hinzufügen-fno-Ausnahme Compiler-Option hat den Trick. Aber ich möchte wirklich Sachen hinter diesem Thema verstehen. Darüber hinaus bedeutet die -fno-Ausnahme, dass ich die Ausnahmebehandlung in meiner Anwendung nicht ausführen kann, nicht, dass ich sie jetzt verwende, aber möglicherweise in der Zukunft.

Danke.

+0

Bitte geben Sie Sprache und Compiler verwendet (für beide Plattformen). Das klingt nach C++, aber es ist besser, explizit zu sein. – unwind

+0

Es würde auch helfen, zu wissen, welches OS als das pthread-Paket oft OS-spezifisch ist. – Benoit

+0

Ich würde auch vorschlagen, die genaue Version des Linux-Kernels aufzuführen, welche Zielplattform-Unterstützung in jedem Fall verwendet wird, und die Versionen von gcc/g ++, libc und anderer involvierter Software. Ohne genaue Versionsnummern ist es ziemlich schwer mit guten Ratschlägen zu kommen. – jakobengblom2

Antwort

2

Thread-Löschung ohne die Hilfe von der Anwendung ist eine schlechte Idee. Nur google. Es ist viel besser, dem Thread zu sagen, dass er sich selbst beenden soll, indem er eine Flag-Variable setzt, die regelmäßig vom Thread überprüft wird.

Eigentlich ist die Löschung so schwierig, dass sie im letzten C++ 0x-Entwurf weggelassen wurde. Sie können http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html suchen und finden keine Angabe von Stornierung überhaupt. Hier ist die Definition der vorgeschlagenen Thread-Klasse (Sie finden dort nicht abbrechen):

class thread 
{ 
public: 
    // types: 
    class id; 
    typedef implementation-defined native_handle_type; // See [thread.native] 

    // construct/copy/destroy: 
    thread(); 
    template <class F> explicit thread(F f); 
    template <class F, class ...Args> thread(F&& f, Args&&... args); 
    ~thread(); 
    thread(const thread&) = delete; 
    thread(thread&&); 
    thread& operator=(const thread&) = delete; 
    thread& operator=(thread&&); 

    // members: 
    void swap(thread&&); 
    bool joinable() const; 
    void join(); 
    void detach(); 
    id get_id() const; 
    native_handle_type native_handle(); // See [thread.native] 

    // static members: 
    static unsigned hardware_concurrency(); 
}; 
+0

Ich habe mich für so etwas entschieden. Ich entschied mich einfach weg von pthread_cancel und dem Durcheinander, das es bringen konnte. Ich habe gerade eine Flag-Variable hinzugefügt, die den Status des Threads angibt, und den Status in einigen Bereichen überprüft, die als Abbruchpunkte gekennzeichnet sind. Ich habe auch ein SIGINT gesendet, um E/A-Anrufe zu blockieren. Auf diese Weise hätte ich volle Kontrolle über die Löschungspunkte und der Thread wäre in der Lage, die ganze Zeit sauber und elegant zu beenden. Vielen Dank! –

Verwandte Themen