Recent Posts

Pages: 1 2 [3] 4 5 ... 10
Thank you for the information. I am attempting to recreate the problem.
Sorry forgot to mention it works on Win32 only fails on x64
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
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.
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)
            return counter; 
         } ) );
      runThreads = false;
      long long total = 0;
      for (auto& ftr : results)
         total += ftr.get();
      cout << total << cout << endl;
Thank you for correcting me and clarifying sequential ordering semantics.
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.
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, std::memory_order_relaxed);
register int ry = y.load(std::memory_order_relaxed);

//Thread running Processor 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, std::memory_order_relaxed);
register int ry = y.load(std::memory_order_seq_cst);

// Thread running on Processor 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.
OK, new packages have been uploaded. Please let me know if you have any further problems.
Thanks for quick response
Pages: 1 2 [3] 4 5 ... 10