How to resolve this problem?

[mcgrady-forever]

When my server run a couple of days, the cpu load will rise a lot, the thread stack is blow:

Thread 1 (process 31689): #0 0x00007fabc470ad2f in do_futex_wait () from /usr/lib64/libpthread.so.0 #1 0x00007fabc470ae07 in __new_sem_wait_slow () from /usr/lib64/libpthread.so.0 #2 0x00007fabc470aea5 in sem_post@@GLIBC_2.2.5 () from /usr/lib64/libpthread.so.0 #3 0x00000000007edded in timed_wait (usecs=5000, this=) at /xxx/xxx/concurrentqueue/blockingconcurrentqueue.h:226 #4 waitWithPartialSpinning (timeout_usecs=, this=) at /XXX/XXX/concurrentqueue/blockingconcurrentqueue.h:282 #5 wait (timeout_usecs=5000, this=) at /XXX/XXX/concurrentqueue/blockingconcurrentqueue.h:362

Whether the timed_wait method will cause deadlock?

[silviucpp]

Are you sure is not the same case as here https://github.com/cameron314/concurrentqueue/issues/271 ?

[cameron314]

Indeed sounds similar to #271.

Note that the call stack shown here is of a thread that's blocking (not consuming any CPU). timed_wait cannot deadlock, but it could wait indefinitely if there's no items being put into the queue.

From the callstack it also seems like you're using a slightly older version of the queue; there were a few bugs in the semaphore implementation at one point, so I would suggest checking if it still reproduces after upgrading.

[mcgrady-forever]

Thanks for you suggestion, I indeed use an old version, and I will upgrade it to the latest version.

[silviucpp]

@cameron314 maybe you should document in readme the case for short living threads.

[cameron314]

@cameron314 maybe you should document in readme the case for short living threads.

Definitely, slipped off my radar last time but I'll make sure to update it soon. The ifdef was supposed to be temporary but it turned out the C++11 support it leveraged is broken on many platforms.