21
General Discussion about just::thread / Re: call to future::wait() aborts the program
« Last post by Anthony Williams on May 09, 2013, 08:12:00 AM »Thank you for the information. I am attempting to recreate the problem.
News:
just::thread V1.8.0 for Windows, Linux and MacOSX Released
Recent Posts
22
General Discussion about just::thread / Re: call to future::wait() aborts the program
« Last post by oleg@completedb.com on May 08, 2013, 07:02:19 PM »Sorry forgot to mention it works on Win32 only fails on x64
23
General Discussion about just::thread / Re: call to future::wait() aborts the program
« Last post by oleg@completedb.com on May 08, 2013, 06:57:40 PM »OS: Windows 8 Pro
Processors: 2 x Intel Xeon E5-2620
Logical Cores: 24
RAM: 64 GB
Microsoft Visual Studio Professional 2012: Version 11.0.60315.01 Update 2
Build: 17.00.60315.1
C++ Command Line:
/Yu"stdafx.h" /GS /GL /W3 /Gy /Zc:wchar_t /I"C:\Program Files (x86)\JustSoftwareSolutions\JustThread\include" /Zi /Gm- /O2 /sdl /Fd"x64\Release\vc110.pdb" /fp:precise /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\" /Fp"x64\Release\FutureWaitFailed.pch"
For some reason I can not attach the file, wanted to send you Visual Studio solution with source files. If you do not mind I will email it. Its small.
If you run it do not forget to change include and lib path to just thread as on my system it maybe in a different place
Processors: 2 x Intel Xeon E5-2620
Logical Cores: 24
RAM: 64 GB
Microsoft Visual Studio Professional 2012: Version 11.0.60315.01 Update 2
Build: 17.00.60315.1
C++ Command Line:
/Yu"stdafx.h" /GS /GL /W3 /Gy /Zc:wchar_t /I"C:\Program Files (x86)\JustSoftwareSolutions\JustThread\include" /Zi /Gm- /O2 /sdl /Fd"x64\Release\vc110.pdb" /fp:precise /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\" /Fp"x64\Release\FutureWaitFailed.pch"
For some reason I can not attach the file, wanted to send you Visual Studio solution with source files. If you do not mind I will email it. Its small.
If you run it do not forget to change include and lib path to just thread as on my system it maybe in a different place
24
General Discussion about just::thread / Re: call to future::wait() aborts the program
« Last post by Anthony Williams on May 08, 2013, 05:10:17 PM »I am sorry to hear that you are experiencing problems.
What OS are you running? Which build of VS2012 are you using? (Open a VS2012 command prompt and type "cl") What compiler options are you using?
I cannot reproduce the problem on Windows 7 x64 with VS 2012, build 17.00.50727.1, on a 6-core machine.
I don't have access to a 24-core system just now, but I do have an 8-core one (also running Windows 7). I don't see that the number of cores should make a difference, but I'll try it out in case it does.
What OS are you running? Which build of VS2012 are you using? (Open a VS2012 command prompt and type "cl") What compiler options are you using?
I cannot reproduce the problem on Windows 7 x64 with VS 2012, build 17.00.50727.1, on a 6-core machine.
I don't have access to a 24-core system just now, but I do have an 8-core one (also running Windows 7). I don't see that the number of cores should make a difference, but I'll try it out in case it does.
25
General Discussion about just::thread / call to future::wait() aborts the program
« Last post by oleg@completedb.com on May 08, 2013, 04:35:04 PM »System has 24 logical processors
Compiled under Visual Studio 2012 x64
The same code below runs fine using native Microsoft implementation and fails most of the time when using just::threads
The exact place where it fails is on ftr.wait()
Please advise
for (unsigned i = 0; i < 10; i++)
{
const unsigned THREAD_COUNT = thread::hardware_concurrency() - 1;
const unsigned SECOND_COUNT = 1;
volatile bool runThreads = true;
vector<future<long long>> results;
for (unsigned u = 0; u < THREAD_COUNT; u++)
{
results.emplace_back ( async( [&] ()
{
long long counter = 0;
while (runThreads)
{
counter++;
}
return counter;
} ) );
}
this_thread::sleep_for(chrono::seconds(SECOND_COUNT));
runThreads = false;
long long total = 0;
for (auto& ftr : results)
{
ftr.wait();
total += ftr.get();
}
cout << total << cout << endl;
}
Compiled under Visual Studio 2012 x64
The same code below runs fine using native Microsoft implementation and fails most of the time when using just::threads
The exact place where it fails is on ftr.wait()
Please advise
for (unsigned i = 0; i < 10; i++)
{
const unsigned THREAD_COUNT = thread::hardware_concurrency() - 1;
const unsigned SECOND_COUNT = 1;
volatile bool runThreads = true;
vector<future<long long>> results;
for (unsigned u = 0; u < THREAD_COUNT; u++)
{
results.emplace_back ( async( [&] ()
{
long long counter = 0;
while (runThreads)
{
counter++;
}
return counter;
} ) );
}
this_thread::sleep_for(chrono::seconds(SECOND_COUNT));
runThreads = false;
long long total = 0;
for (auto& ftr : results)
{
ftr.wait();
total += ftr.get();
}
cout << total << cout << endl;
}
26
General Discussion about just::thread / Re: just::thread std::atomic<T>::load(std::memory_order_seq_cst) Implementation
« Last post by oleg@completedb.com on May 08, 2013, 02:15:51 AM »Thank you for correcting me and clarifying sequential ordering semantics.
27
General Discussion about just::thread / Re: just::thread std::atomic<T>::load(std::memory_order_seq_cst) Implementation
« Last post by Anthony Williams on May 07, 2013, 08:26:56 PM »Operations with memory_order_relaxed can be freely reordered with other operations. In particular, they can be reordered with loads with memory_order_seq_cst unless they are to the same atomic variable. A load does not introduce any memory ordering constraints on the current thread, unless all operations involved are memory_order_seq_cst.
Therefore, I don't believe there is a problem with Just::Thread.
Therefore, I don't believe there is a problem with Just::Thread.
28
General Discussion about just::thread / just::thread std::atomic<T>::load(std::memory_order_seq_cst) Implementation
« Last post by oleg@completedb.com on May 07, 2013, 06:21:38 PM »According to Intel documentation “Loads May Be Reordered with Earlier Stores to Different Locations”
Below is pseudo code
Initial values
std::atomic<int> x = 0;
std::atomic<int> y = 0;
So when using relaxed memory model
//Thread running on Processor 0
x.store(1, std::memory_order_relaxed);
register int ry = y.load(std::memory_order_relaxed);
//Thread running Processor 1
y.store(1, std::memory_order_relaxed);
register int rx = x.load(std::memory_order_relaxed);
//rx == 0 and ry == 0 IS ALLOWED
(copied from intel's doc_ -> At each processor, the load and the store are to different locations and hence may be reordered. Any interleaving
of the operations is thus allowed. One such interleaving has the two loads occurring before the two stores. This
would result in each load returning value 0.
Now when using sequential memory model
// Thread running on Processor 0
x.store(1, std::memory_order_relaxed);
register int ry = y.load(std::memory_order_seq_cst);
// Thread running on Processor 1
y.store(1, std::memory_order_relaxed);
register int rx = x.load(std::memory_order_seq_cst);
//rx == 0 and ry == 0 SHOULD NOT BE ALLOWED BECAUSE load uses memory_order_seq_cst
If my understanding is correct (please correct me if I am wrong), then just::thread load implementation should not use simple mov, but have an appropriate memory barrier to not allow stores to sink below loads.
Below is pseudo code
Initial values
std::atomic<int> x = 0;
std::atomic<int> y = 0;
So when using relaxed memory model
//Thread running on Processor 0
x.store(1, std::memory_order_relaxed);
register int ry = y.load(std::memory_order_relaxed);
//Thread running Processor 1
y.store(1, std::memory_order_relaxed);
register int rx = x.load(std::memory_order_relaxed);
//rx == 0 and ry == 0 IS ALLOWED
(copied from intel's doc_ -> At each processor, the load and the store are to different locations and hence may be reordered. Any interleaving
of the operations is thus allowed. One such interleaving has the two loads occurring before the two stores. This
would result in each load returning value 0.
Now when using sequential memory model
// Thread running on Processor 0
x.store(1, std::memory_order_relaxed);
register int ry = y.load(std::memory_order_seq_cst);
// Thread running on Processor 1
y.store(1, std::memory_order_relaxed);
register int rx = x.load(std::memory_order_seq_cst);
//rx == 0 and ry == 0 SHOULD NOT BE ALLOWED BECAUSE load uses memory_order_seq_cst
If my understanding is correct (please correct me if I am wrong), then just::thread load implementation should not use simple mov, but have an appropriate memory barrier to not allow stores to sink below loads.
29
General Discussion about just::thread / Re: Missing jss/forwarding_constructors.hpp
« Last post by Anthony Williams on May 02, 2013, 09:51:43 AM »OK, new packages have been uploaded. Please let me know if you have any further problems.
30
General Discussion about just::thread / Re: Missing jss/forwarding_constructors.hpp
« Last post by oleg@completedb.com on May 01, 2013, 05:29:11 PM »Thanks for quick response