From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-371897-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 14705 invoked by alias); 26 Oct 2011 12:42:11 -0000
Received: (qmail 14695 invoked by uid 22791); 26 Oct 2011 12:42:10 -0000
X-SWARE-Spam-Status: No, hits=-2.9 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from localhost (HELO gcc.gnu.org) (127.0.0.1)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 26 Oct 2011 12:41:52 +0000
From: "bartosz.szurgot at pwr dot wroc.pl" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/50862] deadlock in std::condition_variable_any
Date: Wed, 26 Oct 2011 12:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: bartosz.szurgot at pwr dot wroc.pl
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.6.3
X-Bugzilla-Changed-Fields:
Message-ID: <bug-50862-4-SbGMinAMM1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-50862-4@http.gcc.gnu.org/bugzilla/>
References: <bug-50862-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2011-10/txt/msg02641.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50862

--- Comment #11 from bartek 'basz' szurgot <bartosz.szurgot at pwr dot wroc.pl> 2011-10-26 12:41:34 UTC ---
i'm not sure about uncaught_exception(). i remember reading in Herb Sutter's
that it's usage should be avoided, since it has some flaw, that makes it's
return value unsure. but this was written in times of C++03 and i can't
remember what was the reasoning behind it (threading perhaps?), so i do not
know if it still holds for C++11 as well or not. any way there is still a
possibility of exception throwing from d-tor, which would be better to avoid.

for now my proposal to overcome this is something like:

struct _Unlock
{
  explicit _Unlock(_Lock& __lk) : _M_lock(&__lk) { __lk.unlock(); }
  ~_Unlock()
  {
    try
    {
      if(_M_lock)
        _M_lock->lock();
    }
    catch(...){}
  }
  _Lock &release(void)
  {
     _Lock* tmp=_M_Lock;
     _M_Lock=nullptr;
     return *tmp;
  }
private:
  _Lock* _M_lock;
};

unique_lock<mutex> __my_lock(_M_mutex);
_Unlock __unlock(__lock);
unique_lock<mutex> __my_lock2(std::move(__my_lock));
_M_cond.wait(__my_lock2);
__unlock.release().lock(); // if no exception so far - may throw here

general idea is to call lock() in d-tor inside the try-catch block, in case of
any exception, anywhere in the method, and if there was no one risen until the
last line we take responsibility for calling lock() from __unlock and call it
explicitly, so that exception can always be safely thrown from that call.

but perhaps we'd be able to come out with some better/cleaner/shorter solution
for this problem?