[llvm-bugs] [Bug 37818] New: condition_variable::wait_for () should always unlock/lock
via llvm-bugs
llvm-bugs at lists.llvm.org
Fri Jun 15 13:29:37 PDT 2018
https://bugs.llvm.org/show_bug.cgi?id=37818
Bug ID: 37818
Summary: condition_variable::wait_for () should always
unlock/lock
Product: libc++
Version: 6.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: lewis at sophists.com
CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com
Note - similar to 21395, except reasoning is very different.
http://en.cppreference.com/w/cpp/thread/condition_variable/wait_for says:
... Atomically releases lock, blocks the current executing thread, and adds
it to the list of threads waiting on *this
For the most part this is true with the libc++ implementation, but not when
if (__d <= __d.zero())
return cv_status::timeout;
for comparison, see
libstdc++ does
(https://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/a00818_source.html)
template<typename _Lock, typename _Clock, typename _Duration>
00217 cv_status
00218 wait_until(_Lock& __lock,
00219 const chrono::time_point<_Clock, _Duration>& __atime)
00220 {
00221 unique_lock<mutex> __my_lock(_M_mutex);
00222 __lock.unlock();
00223 cv_status __status = _M_cond.wait_until(__my_lock,
__atime);
00224 __lock.lock();
00225 return __status;
00226 }
unconditionally unlock/lock (even if we are going to get a timeout).
This is IMPORTANT, because if you wait_for (0) a bunch of times (stupid but not
illegal). and in another thread try to get the mutex for the variable, before
setting it, you may infinite loop (because the 'signal'ing thread never gets
the lock).
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180615/0924c7c5/attachment.html>
More information about the llvm-bugs
mailing list