Fdhvdu / ThreadPool

A fastest, exception-safety and pure C++17 thread pool.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Get stuck when running example with threadpool 1024

WanpengQian opened this issue · comments

change example.cpp pool size to 1024

using namespace std;
	nThread::CThreadPool tp{1024};
	queue<nThread::CThreadPool::thread_id> que;

and running the test. get stuck as following output

add - thread 752 wait 3 sec
add_and_detach - thread 1024 wait 1 sec
add - thread 762 wait 0 sec
add_and_detach - thread 1024 wait 2 sec
add_and_detach - thread 1024 wait 3 sec
add - thread 758 wait 2 sec
add_and_detach - thread 1024 wait 1 sec
add - thread 759 wait 2 sec
add_and_detach - thread 1024 wait 2 sec
add - thread 755 wait 3 sec
add_and_detach - thread 1024 wait 3 sec
add - thread 757 wait 3 sec
add - thread 763 wait 1 sec
add - thread 760 wait 3 sec
add_and_detach - thread 1024 wait 3 sec
add - thread 767 wait 1 sec
add - thread 764 wait 2 sec
add - thread 765 wait 2 sec
add - thread 768 wait 1 sec
add - thread 766 wait 3 sec

Would you mind to give me more information?
Such as, gcc version, running environment, compilation options and cpu.
Of course, it may due to code bug.

I am using Visual Studio 2017 Community, Version 15.9.7
OS: Windows 10 1809 build 17763.384
C++ compile option is

/JMC /permissive- /GS /analyze- /W3 /Zc:wchar_t /ZI /Gm- /Od /sdl /Fd"Debug\vc141.pdb" /Zc:inline /fp:precise /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /Oy- /MDd /std:c++17 /FC /Fa"Debug\" /EHsc /nologo /Fo"Debug\" /Fp"Debug\ThreadPoolTest.pch" /diagnostics:classic 

The machine is Thinkpad T480s, i5 8250u 4core8thread, 24G ram. with 512GB SSD.
Thanks.

checking out the code again, without compile error.
and build under Linux & Windows again.
the code runs fine under Linux with following OS information.

wanpengqian@dev:~/threadpool/ThreadPool$ uname -a
Linux dev 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
wanpengqian@dev:~/threadpool/ThreadPool$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04) 

and the same dead lock? under Windows 10 (version info, see the last post.)

add_and_detach - thread 1024 wait 1 sec
add - thread 755 wait 1 sec
add - thread 750 wait 2 sec
add - thread 751 wait 2 sec
add - thread 752 wait 2 sec
add_and_detach - thread 1024 wait 3 sec
add_and_detach - thread 1024 wait 1 sec
add - thread 760 wait 0 sec
add_and_detach - thread 1024 wait 2 sec
add - thread 761 wait 0 sec
add_and_detach - thread 1024 wait 1 sec
add_and_detach - thread 1024 wait 2 sec
add - thread 763 wait 0 sec
add - thread 757 wait 2 sec
add - thread 753 wait 3 sec
add - thread 756 wait 3 sec
add_and_detach - thread 1024 wait 1 sec
add - thread 764 wait 0 sec
add - thread 762 wait 1 sec
add - thread 759 wait 2 sec
add - thread 758 wait 3 sec
add_and_detach - thread 1024 wait 2 sec
add_and_detach - thread 1024 wait 3 sec
add_and_detach - thread 1024 wait 3 sec
add - thread 766 wait 1 sec
add_and_detach - thread 1024 wait 3 sec
add - thread 768 wait 1 sec
add - thread 767 wait 2 sec
add - thread 765 wait 3 sec

Sorry for the late reply. I doubt it is library problem.
May you use the default constructor? (It is best for performance issue, not just for fixing this problem.)

I post a question here.
Maybe it is a bug?