|
|
Threads-Devel : |
Subject: Re: [Threads-devel] Fwd: cond.timed_wait() returns way after deadline?
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2009-07-09 09:53:04
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 09 July 2009, Stefan Steuerwald wrote:
> 2009/7/9 Frank Mori Hess <frank.hess_at_[hidden]>:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Thursday 09 July 2009, Stefan Steuerwald wrote:
> >> Dear threaders,
> >>
> >> I have this code:
> >>
> >> Â Â Â Â unique_lock<mutex> lock(mut);
> >> Â Â Â Â system_time deadline = get_system_time() + timeout;
> >> Â Â Â Â while( some_pred() ) {
> >> Â Â Â Â Â Â Â Â if( ! cond.timed_wait( lock, deadline ) )
> >> Â Â Â Â Â Â Â Â Â Â Â Â break;
> >> Â Â Â Â }
> >>
> >> boost 1.37.0 on a linux 2.6.30.1 kernel.
> >> Works fine 99% of the time. Sometimes however, I see timed_wait()
> >> returning several seconds AFTER the deadline (timeout is 5000ms).
> >> I wonder what could cause such behaviour?
> >
> > You didn't show the notify end of the code. Â Does it lock the same mutex
> > before calling notify?
>
> Sorry, right. It looks like this:
>
> unique_lock<mutex> lock(mut);
> // some variable updates here
> lock.unlock();
> cond.notify_all();
Is there any reason you unlock before calling notify_all? I know it is
supposed to work, but you could in principle go back to waiting after a
notify if the predicate is made true by one thread then a different thread
makes if false again before the timed_wait receives the notify and reacquires
the mutex.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpV9kAACgkQ5vihyNWuA4XHIQCffbmOxCz8R5wgIvtPXC7cs1za
+kMAniJF8TqjCVD/Xsx6PZ9kdkJHQkHF
=lWfH
-----END PGP SIGNATURE-----