代码之家  ›  专栏  ›  技术社区  ›  kreuzerkrieg

boost asio计时器是否应在“取消”时阻塞?

  •  1
  • kreuzerkrieg  · 技术社区  · 7 年前

    我注意到 boost::asio::steady_timer cancel 调用并提供回调 async_wait 正在执行。是预期的行为吗?它是可配置的吗?为什么一开始就要堵住?

    调用堆栈:

    #0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
    #1  0x00007f4d4c703dbd in __GI___pthread_mutex_lock (mutex=0x20000616f558) at ../nptl/pthread_mutex_lock.c:80
    #2  0x000070000086ef75 in boost::asio::detail::posix_mutex::lock (this=0x20000616f558) at /source/boost/include/boost/asio/detail/posix_mutex.hpp:52
    #3  0x000070000087036e in boost::asio::detail::conditionally_enabled_mutex::scoped_lock::scoped_lock (this=0x40000623e970, m=...) at /source/boost/include/boost/asio/detail/conditionally_enabled_mutex.hpp:55
    #4  0x00007000009ebf7f in boost::asio::detail::epoll_reactor::cancel_timer<boost::asio::detail::chrono_time_traits<std::chrono::_V2::steady_clock, boost::asio::wait_traits<std::chrono::_V2::steady_clock> > > (this=0x20000616f520, queue=..., timer=..., 
        max_cancelled=18446744073709551615) at /source/boost/include/boost/asio/detail/impl/epoll_reactor.hpp:62
    #5  0x00007000009e8322 in boost::asio::detail::deadline_timer_service<boost::asio::detail::chrono_time_traits<std::chrono::_V2::steady_clock, boost::asio::wait_traits<std::chrono::_V2::steady_clock> > >::cancel (this=0x200006188f60, impl=..., ec=...)
        at /source/boost/include/boost/asio/detail/deadline_timer_service.hpp:144
    #6  0x00007000009e5211 in boost::asio::basic_waitable_timer<std::chrono::_V2::steady_clock, boost::asio::wait_traits<std::chrono::_V2::steady_clock> >::cancel (this=0x20009470cfc8)
        at /source/boost/include/boost/asio/basic_waitable_timer.hpp:329
    
    1 回复  |  直到 7 年前
        1
  •  0
  •   kreuzerkrieg    7 年前

    看起来问题是因为我们在多进程环境中工作。所有进程共享同一内存,在此共享内存上创建的所有对象,包括互斥体、线程等。在这种情况下,系统中使用的互斥体是用 PTHREAD_PROCESS_SHARED 属性。显然, asio 互斥对象不是用这样的属性创建的,所以我想这是互斥对象被困在意外位置的问题。一旦 io_context steady_timer 只在一个进程中开始执行它按预期开始工作

    推荐文章