[interprocess] difference in timed_wait behavior under linux and windows
Hello, I have the following issue, when I'm calling interprocess_condition.timed_wait with time equals to boost::posix_time::pos_infin it has different behavior under linux and under windows. Under windows it is similar to interprocess_condition.wait, but under linux it fails with assertion here: file boost\interprocess\sync\posix\interprocess_condition.hpp: inline bool interprocess_condition::do_timed_wait (const boost::posix_time::ptime &abs_time, interprocess_mutex &mut) { timespec ts = detail::ptime_to_timespec(abs_time); pthread_mutex_t* pmutex = &mut.m_mut; int res = 0; res = pthread_cond_timedwait(&m_condition, pmutex, &ts); assert(res == 0 || res == ETIMEDOUT); return res != ETIMEDOUT; } I don't know which behavior is better, but I suggest it should be the same for both OSes. Best Regards, Sergei
Sergei Politov wrote:
Hello,
I have the following issue, when I'm calling interprocess_condition.timed_wait with time equals to boost::posix_time::pos_infin it has different behavior under linux and under windows.
Under windows it is similar to interprocess_condition.wait, but under linux it fails with assertion here: file boost\interprocess\sync\posix\interprocess_condition.hpp:
inline bool interprocess_condition::do_timed_wait (const boost::posix_time::ptime &abs_time, interprocess_mutex &mut) { timespec ts = detail::ptime_to_timespec(abs_time); pthread_mutex_t* pmutex = &mut.m_mut; int res = 0; res = pthread_cond_timedwait(&m_condition, pmutex, &ts); assert(res == 0 || res == ETIMEDOUT);
return res != ETIMEDOUT; }
Thanks for the report. I just didn't know pos_infin was there. I would need to call non-timed versions when pos_infin is used. That would be correct, wouldn't it?
I don't know which behavior is better, but I suggest it should be the same for both OSes.
Best Regards, Sergei
Regards, Ion
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hello, On Fri, Sep 19, 2008 at 9:30 PM, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Thanks for the report. I just didn't know pos_infin was there. I would need to call non-timed versions when pos_infin is used. That would be correct, wouldn't it?
Yep, I did it in the same way. There is one more thing, I want to discuss. I have done some performance tests of my "stream transporter" class that uses shared_memory, interprocess_condition, interprocess_mutex. And windows version was 2.5 times faster than linux. When I turned linux version to BOOST_INTERPROCESS_USE_GENERIC_EMULATION it produced the same speed. The problem is that I had to edit boost header files to do so. I think it would be nice to add ability to do it "externally". Best Regards, Sergei
Sergei Politov wrote:
Hello,
On Fri, Sep 19, 2008 at 9:30 PM, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Thanks for the report. I just didn't know pos_infin was there. I would need to call non-timed versions when pos_infin is used. That would be correct, wouldn't it?
Yep, I did it in the same way.
Ok.
There is one more thing, I want to discuss. I have done some performance tests of my "stream transporter" class that uses shared_memory, interprocess_condition, interprocess_mutex. And windows version was 2.5 times faster than linux. When I turned linux version to BOOST_INTERPROCESS_USE_GENERIC_EMULATION it produced the same speed. The problem is that I had to edit boost header files to do so.
Ok. Generic emulation uses atomic operations to emulate locks and condition variables. The problem with generic emulation is that condition variables don't sleep, they spin (with yield()). For some applications that use mutexes without high contention, generic emulation is faster. For other applications, this might not be true. Anyway, I think it's fair to offer an option to force the use of generic emulation. Thanks for the idea!
Best Regards, Sergei
Regards, Ion
participants (2)
-
Ion Gaztañaga -
Sergei Politov