C++ - Exception-Handling In Kritischen Abschnitt (pthreads)

Ist das eigentlich Bombardierung, nachdem eine Ausnahme? Weit mehr wahrscheinlich von Ihrem Ausschnitt, dass Sie nur noch schlechte Synchronisation statt. Das beginnt mit dem Namen des mutex: "writeMutex". Dies ist nicht zur Arbeit gehen, wenn es auch ein "readMutex". Alle Lesen, gucken und Schreiboperationen gesperrt werden müssen, indem die gleichen mutex.

plus

was macht die pop Aussehen

erstellen Sie eine lock-wrapper-Klasse, die automatisch freie die Verriegelung, wenn Sie den Bereich verlässt (wie in RAII Kommentar)

c++ nicht endlich (vielen Dank an Herrn stoustrop wird stroppy)

ich würde fangen std::exception oder gar keine (Enten Kopf nach unten für die Flammen-Krieges). Wenn u fangen Sie keine, dann müssen Sie den wrapper

Müssen Sie die Verwendung von RAII

Grundsätzlich bedeutet dies, dass mit dem Konstruktor/Destruktor zu sperren/entsperren der Ressource.

Dadurch ergibt sich, dass der mutex wird immer freigeschaltet, auch wenn Ausnahmen vorhanden sind.

Sollte man nur mit einem mutex für den Zugriff auf der Liste.

Auch wenn Sie eine nur-lese-mutex, die von einem thread, der nur liest. Das bedeutet nicht, es ist sicher zu Lesen, wenn ein anderer thread die Aktualisierung der Warteschlange. Die Warteschlange könnte in gewissen zwischen-Zustand, verursacht durch einen thread aufrufen von push (), während ein anderer thread versucht, ti navigieren eine invlide Zwischenstand.

class Locker
{
    public:
        Locker(pthread_mutex_t &lock)
            :m_mutex(lock)
        {
            pthread_mutex_lock(&m_mutex);
        }
        ~Locker()
        {
            pthread_mutex_unlock(&m_mutex);
        }
    private:
        pthread_mutex_t&    m_mutex;
};

int Queue::push( WorkUnit unit )
{
    //building the object lock calls the constructor thus locking the mutex.
    Locker  lock(_writeMutex);
    int errorCode = 0;

    try
    {
        _queue.push_back( unit );
    }
    catch( std::bad_alloc )  //Other exceptions may happen here.
    {                        //You catch one that you handle locally via error codes. 
        errorCode = 1;       //That is fine. But there are other exceptions to think about.
    }

    return errorCode;
}  //lock destructor called here. Thus unlocking the mutex.

PS. Ich hasse die Verwendung von führenden Unterstrich.

Obwohl technisch ist es OK (vorausgesetzt, member-Variablen) es ist so einfach zu Durcheinander, dass ich lieber nicht zu pre-pend '' zu idnetifiers. Sehen Was sind die Regeln über die Verwendung eines Unterstriches in einem C++ - Bezeichner? für eine ganze Liste von Regeln zu tun über '' in Bezeichner-Namen.

Ausführen von code unter jedem instrumentation software dient keinem Zweck.
Sie haben zu Recht-code, das funktioniert nicht führen Sie es unter valgrind.

In C funktioniert es einwandfrei:

pthread_cleanup_pop( 0 );
r = pthread_mutex_unlock( &mutex );
if ( r != 0 )
{
    /* Explicit error handling at point of occurance goes here. */
}

Aber weil c++ ist eine software, die Abtreibung gibt es einfach keine vernünftige Möglichkeit, den Umgang mit threaded kodiert Ausfälle mit jedem Grad der Gewissheit. Gehirn-Toten Ideen wie Geschenkpapier pthread_mutex_t in einer Klasse, fügt eine Art state-variable ist nur, dass - brain dead. Der folgende code funktioniert einfach nicht:

Locker::~Locker()
{
    if ( pthread_mutex_unlock( &mutex ) != 0 )
    {
        failed = true; //Nonsense.
    }
}

Und der Grund dafür ist, dass nach pthread_mutex_unlock() gibt in diesem thread sehr gut in Scheiben geschnitten werden aus der cpu - verdrängt. Das bedeutet, dass die .fehlgeschlagen öffentliche variable wird immer noch falsch. Andere threads anschaut, wird es falsche Angaben, die state-variable sagt keine Fehler, mittlerweile pthread_mutex_unlock() ist fehlgeschlagen. Auch wenn, wie durch ein Glücksfall, diese beiden Anweisungen führen Sie in eine gehen, dieser thread kann verdrängt werden, bevor ~Schrank() gibt und andere threads können den Wert ändern, der von .fehlgeschlagen. Bottom line diese Systeme funktionieren nicht - es gibt keine Atomare test-and-set-Mechanismus für die Anwendung definierte Variablen.

Einige sagen, Destruktoren sollten niemals code, der scheitert. Alles andere ist ein schlechtes design. Ok, in Ordnung. Ich bin einfach nur neugierig zu sehen, was ein gutes design ist zu 100% Ausnahme-und thread-sicher in c++.