public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/57641] New: std::timed_mutex.try_lock_until() is broken
@ 2013-06-18 16:29 mustrumr97 at gmail dot com
2013-06-18 16:58 ` [Bug libstdc++/57641] " redi at gcc dot gnu.org
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: mustrumr97 at gmail dot com @ 2013-06-18 16:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
Bug ID: 57641
Summary: std::timed_mutex.try_lock_until() is broken
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mustrumr97 at gmail dot com
It uses the duration since the time_point's clock's epoch. What if it's not the
right clock? Different clocks may have different epochs. On my computer, the
function works OK if the time_point is from high_resolution_clock but doesn't
work if it's from steady_clock.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
2013-06-18 16:29 [Bug libstdc++/57641] New: std::timed_mutex.try_lock_until() is broken mustrumr97 at gmail dot com
@ 2013-06-18 16:58 ` redi at gcc dot gnu.org
2013-06-18 17:22 ` mustrumr97 at gmail dot com
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2013-06-18 16:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I agree that code assumes the epochs are the same, but what you describe
doesn't make sense since high_resolution_clock and steady_clock have the same
epoch in our implementation. Are you seeing the first problem described at PR
54562?
Do you have a testcase?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
2013-06-18 16:29 [Bug libstdc++/57641] New: std::timed_mutex.try_lock_until() is broken mustrumr97 at gmail dot com
2013-06-18 16:58 ` [Bug libstdc++/57641] " redi at gcc dot gnu.org
@ 2013-06-18 17:22 ` mustrumr97 at gmail dot com
2013-06-18 17:27 ` redi at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: mustrumr97 at gmail dot com @ 2013-06-18 17:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #2 from Hristo Venev <mustrumr97 at gmail dot com> ---
Am I very stupid, or is
#include <mutex>
#include <chrono>
using Clock=std::chrono::steady_clock;
int main(){
std::timed_mutex m;
m.lock();
Clock::time_point tp=Clock::now()+std::chrono::seconds(2);
if(m.try_lock_until(tp)) return 1;
return 0;
}
supposed to run for ~2s and return 0?
With clang++ -stdlib=libc++ it works as I expect.
With clang++ -stdlib=libstdc++ and with g++ it returns 1 after 0.001s.
The result is the same for std::chrono::high_resolution_clock.
The test from cppreference.com is very similar.
http://en.cppreference.com/w/cpp/thread/timed_mutex/try_lock_until
What the hell is going on?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
2013-06-18 16:29 [Bug libstdc++/57641] New: std::timed_mutex.try_lock_until() is broken mustrumr97 at gmail dot com
2013-06-18 16:58 ` [Bug libstdc++/57641] " redi at gcc dot gnu.org
2013-06-18 17:22 ` mustrumr97 at gmail dot com
@ 2013-06-18 17:27 ` redi at gcc dot gnu.org
2013-06-18 17:28 ` redi at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2013-06-18 17:27 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Testcase using clock with an earlier epoch:
#include <chrono>
#include <thread>
#include <mutex>
#include <assert.h>
namespace C = std::chrono;
struct clock
{
typedef C::system_clock::rep rep;
typedef C::system_clock::period period;
typedef C::system_clock::duration duration;
typedef std::chrono::time_point<clock> time_point;
static constexpr bool is_steady = C::system_clock::is_steady;
static time_point now() {
return time_point(C::system_clock::now().time_since_epoch() +
C::seconds(10));
}
};
std::timed_mutex mx;
void f()
{
mx.try_lock_until(clock::now() + C::milliseconds(1));
}
int main()
{
std::lock_guard<std::timed_mutex> l(mx);
auto start = C::system_clock::now();
std::thread t(f);
t.join();
auto stop = C::system_clock::now();
assert( (stop - start) < C::seconds(9) );
}
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
2013-06-18 16:29 [Bug libstdc++/57641] New: std::timed_mutex.try_lock_until() is broken mustrumr97 at gmail dot com
` (2 preceding siblings ...)
2013-06-18 17:27 ` redi at gcc dot gnu.org
@ 2013-06-18 17:28 ` redi at gcc dot gnu.org
2013-06-18 17:31 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2013-06-18 17:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It's undefined behaviour because you try to lock the same mutex twice in the
same thread, see my testcase for a well-defined way to do it, calling
try_lock_until in a new thread.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
2013-06-18 16:29 [Bug libstdc++/57641] New: std::timed_mutex.try_lock_until() is broken mustrumr97 at gmail dot com
` (3 preceding siblings ...)
2013-06-18 17:28 ` redi at gcc dot gnu.org
@ 2013-06-18 17:31 ` redi at gcc dot gnu.org
2013-06-18 21:42 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2013-06-18 17:31 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-06-18
Ever confirmed|0 |1
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The timed mutex requirements [thread.timedmutex.requirements] say:
The expression m.try_lock_until(abs_time) shall be well-formed and have the
following semantics:
Requires: If m is of type std::timed_mutex, the calling thread does not own the
mutex.
Anyway, confirming as there's a bug here relating to clocks with different
epochs, but it's easy enough to fix, I can look into it. The same problem
exists with the private mutex type defined in std::shared_mutex
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
2013-06-18 16:29 [Bug libstdc++/57641] New: std::timed_mutex.try_lock_until() is broken mustrumr97 at gmail dot com
` (4 preceding siblings ...)
2013-06-18 17:31 ` redi at gcc dot gnu.org
@ 2013-06-18 21:42 ` redi at gcc dot gnu.org
2013-06-18 22:56 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2013-06-18 21:42 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
2013-06-18 16:29 [Bug libstdc++/57641] New: std::timed_mutex.try_lock_until() is broken mustrumr97 at gmail dot com
` (5 preceding siblings ...)
2013-06-18 21:42 ` redi at gcc dot gnu.org
@ 2013-06-18 22:56 ` redi at gcc dot gnu.org
2013-10-07 23:22 ` redi at gcc dot gnu.org
2013-10-07 23:23 ` redi at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2013-06-18 22:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.8.2
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed on trunk, I'll fix this for 4.8.2 as well.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
2013-06-18 16:29 [Bug libstdc++/57641] New: std::timed_mutex.try_lock_until() is broken mustrumr97 at gmail dot com
` (6 preceding siblings ...)
2013-06-18 22:56 ` redi at gcc dot gnu.org
@ 2013-10-07 23:22 ` redi at gcc dot gnu.org
2013-10-07 23:23 ` redi at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2013-10-07 23:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Author: redi
Date: Mon Oct 7 23:21:58 2013
New Revision: 203256
URL: http://gcc.gnu.org/viewcvs?rev=203256&root=gcc&view=rev
Log:
PR libstdc++/57641
* include/std/mutex (timed_mutex, recursive_timed_mutex): Add
overloaded _M_try_lock_until to handle conversion between different
clocks. Replace constrained __try_lock_for_impl overloads with
conditional increment.
* testsuite/30_threads/timed_mutex/try_lock_until/57641.cc: New.
Added:
branches/gcc-4_8-branch/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_until/57641.cc
Modified:
branches/gcc-4_8-branch/libstdc++-v3/ChangeLog
branches/gcc-4_8-branch/libstdc++-v3/include/std/mutex
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
2013-06-18 16:29 [Bug libstdc++/57641] New: std::timed_mutex.try_lock_until() is broken mustrumr97 at gmail dot com
` (7 preceding siblings ...)
2013-10-07 23:22 ` redi at gcc dot gnu.org
@ 2013-10-07 23:23 ` redi at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2013-10-07 23:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
fixed for 4.8.2
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-10-07 23:23 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-18 16:29 [Bug libstdc++/57641] New: std::timed_mutex.try_lock_until() is broken mustrumr97 at gmail dot com
2013-06-18 16:58 ` [Bug libstdc++/57641] " redi at gcc dot gnu.org
2013-06-18 17:22 ` mustrumr97 at gmail dot com
2013-06-18 17:27 ` redi at gcc dot gnu.org
2013-06-18 17:28 ` redi at gcc dot gnu.org
2013-06-18 17:31 ` redi at gcc dot gnu.org
2013-06-18 21:42 ` redi at gcc dot gnu.org
2013-06-18 22:56 ` redi at gcc dot gnu.org
2013-10-07 23:22 ` redi at gcc dot gnu.org
2013-10-07 23:23 ` redi at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).