3. boost::shared_mutex problem

boost::shared_mutex problem

  • F

    Hallo zusammen, ich habe aktuell ein Problem mit einen boost::shared_mutex.
    Daher erstmal 1 Frage vorweg: Funktioniert der auch in verwendung mit posix threads? Das ganze hatte sich historisch so entwickelt. Ansonsten könnte ich die Klassen entsprechend auf boost::thread umstricken.

    Aber nun zum problem, der Thread der auf den shared_mutex exklusiv zugreifen soll blockiert obwohl scheinbar nirgendwo anders zugriff erfolgt. Den exklusiven zugriff möchte ich so erwirken:

    void CPlayerManager::setLoginLogout(bool val)
{
    if ( val ) 
    {
        //anmelden des exklusiven zugriffs
        reloadmutex.lock_upgrade();
        //bekommen des exklusiven zugriffs
        reloadmutex.unlock_upgrade_and_lock(); //<--hier blockts
    }
    else
    {
        //exklusiver zugriff freigeben
        reloadmutex.unlock();
    }
}

    In zwei anderen Threads brauche ich auf den Mutex nur lese zugriff das geschieht prinzipiell so

    reloadmutex.lock_shared(); 
CPlayer * newPlayer = new CPlayer(Connection);
//release shared lock
reloadmutex.unlock_shared();

    GDB meint das keiner der beiden Threads sich gerade in einen zustand befindet welche das lock_shared() oder ähnliches abfragen aber trotz allem Blockiert der Hauptthread. Irgendwie mache ich noch was falsch. Ggf hab ich das prinzip des shared_mutex auch nur falsch verstanden?

    Hier noch der GDB Auszug über den zustand vom reloadmutex

    $2 = {state = {shared_count = 5, exclusive = false, upgrade = true, exclusive_waiting_blocked = false},
  state_change = {<boost::noncopyable_::noncopyable> = {<No data fields>}, m = {__data = {__lock = 0, __count = 0,
        __owner = 0, __kind = 0, __nusers = 1, {__spins = 0, __list = {__next = 0x0}}},
      __size = '\0' <repeats 16 times>, "\001\000\000\000\000\000\000", __align = 0}}, shared_cond = {cond = {__data = {
        __lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0,
        __broadcast_seq = 0}, __size = '\0' <repeats 47 times>, __align = 0}}, exclusive_cond = {cond = {__data = {
        __lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0,
        __broadcast_seq = 0}, __size = '\0' <repeats 47 times>, __align = 0}}, upgrade_cond = {cond = {__data = {
        __lock = 0, __futex = 1, __total_seq = 1, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x83df988, __nwaiters = 2,
        __broadcast_seq = 0},
      __size = "\000\000\000\000\001\000\000\000\001", '\0' <repeats 23 times>, "\210ù=\b\002\000\000\000\000\000\000\000\000\000\000", __align = 4294967296}}}

    hoffe mir kann jemand helfen.

    0
  • F

    Ok, das problem konnte dann doch auf einfache weise behoben werden (hoffe ich) das problem war ein try catch block in dem ein shared_lock eingebettet war, dieser hat den lock nicht freigegeben.

    0
Anmelden zum Antworten