Recent Posts

31

General Discussion about just::thread / Re: Missing jss/forwarding_constructors.hpp

« Last post by Anthony Williams on May 01, 2013, 04:09:35 PM »

Gah! Packaging error!

I'll update the packages and post here when the new versions are available.

Sorry for the inconvenience.

32

General Discussion about just::thread / Missing jss/forwarding_constructors.hpp

« Last post by oleg@completedb.com on May 01, 2013, 02:24:50 PM »

Installed recently downloaded justthread_full.msi
Tried using std::thread but getting compiler error

1>C:\Program Files (x86)\JustSoftwareSolutions\JustThread\include\thread(21): fatal error C1083: Cannot open include file: 'jss/forwarding_constructors.hpp': No such file or directory

manually checked jss directory forwarding_constructors.hpp file is not there

Please Advise

33

General Discussion about just::thread / Re: std::atomic<int>::load implementation on Intel-x64

« Last post by oleg@completedb.com on April 29, 2013, 06:53:24 PM »

Thank you.
We should probably warn C++ world especially those who is implementing lock-free algos where suboptimal code is not an option.

34

General Discussion about just::thread / Re: std::atomic<int>::load implementation on Intel-x64

« Last post by Anthony Williams on April 29, 2013, 06:43:02 PM »

I believe that the VS2012 implementation is being overly conservative. If the appropriate synchronization is used on the store, then an atomic<int>::load need only be a MOV on x86.

Microsoft is trying to phase out the use of volatile for synchronization, and is encouraging people to use std::atomic instead, hence the compiler switch. It is a shame if their library generates suboptimal code in this case.

Just::Thread does not rely on the special semantics of volatile; where our source code uses volatile it is just to force the compiler to issue the load --- the _ReadWriteBarrier() intrinsic is used to restrict reordering by the compiler.

35

General Discussion about just::thread / std::atomic<int>::load implementation on Intel-x64

« Last post by oleg@completedb.com on April 29, 2013, 06:22:54 PM »

We upgraded to Visual Studio 2012 and decided to look into using std::atomic for inter-thread synchronization
Strangely enough Microsoft implementation is using _InterlockedOr (which internally generates lock cmpxchg DWORD PTR [rcx], edx) for std::atomic<int>::load across all memory models (relaxed, acquire, consume and sequential)
I decided to buy just::thread library and try it instead, just::thread is using a read of volatile variable, which is what we have been using explicitly in code up to now to implement Acquire semantics
Microsoft states explicitly that as long as /volatile::ms compiler option is used (which is by default) one can use volatile objects to be used for memory locks and releases.
http://msdn.microsoft.com/en-us/library/vstudio/12a04hfd.aspx

Would love to know why _InterlockedOr is used which potentially can degrade performance with unnecessary memory barrier for Relaxed!!! and Acquire semantics on Intel-x64.
Am I missing something? Or it is a bug in our code and just::thread std::atomic<int>::load implementation?

Thank you in advance.

36

General Discussion about just::thread / Re: jss::synchronized_value

« Last post by Anthony Williams on April 23, 2013, 12:13:46 PM »

Yes, there's a potential race between the test and the set. It's "safe" in the sense that the mutex is held across each access, but it might overwrite a change made by another thread.

This is a dummy example. Probably not a very good one 

jss::update_guard is the companion to jss::synchronized_value that allows safe accesses across multiple statements:

Code: [Select]

jss::synchronized_value<std::string> sv;

void bar(){
    jss::update_guard<std::string> guard(sv);
    if(guard->empty()){
        *guard="hello"; // no potential for a race here.
    }
}


37

General Discussion about just::thread / jss::synchronized_value

« Last post by py on April 23, 2013, 11:41:40 AM »

In the example given:

jss::synchronized_value<std::string> s;

void foo(){
    if(s->empty()){
        *s =  "hello";
    }
}

Is there not a race condition between checking for empty and then assigning to s? Presumably another thread could write to s after the empty check but before the assignment? Or does synchronized_value somehow protect against this?

38

General Discussion about just::thread / cmake

« Last post by dhait on December 02, 2012, 04:51:42 AM »

How about a CMake "FIND_PACKAGE" configuration for Just::Thread?

 

Anyone?

39

General Discussion about just::thread / Re: managed C++ crash

« Last post by nbsystems on November 10, 2012, 01:03:32 AM »

Have you had a chance to look into this further?

40

General Discussion about just::thread / ANNOUNCE: Just::Thread V1.8.0 Released

« Last post by Anthony Williams on August 30, 2012, 05:42:45 PM »

I am pleased to announce that Just::Thread V1.8.0 has been released.

This version now supports Microsoft Visual Studio 2012, so you can continue to benefit from Just::Thread when upgrading your compiler.

There are also minor fixes and improvements that affect all platforms.

As usual, existing customers are entitled to a free upgrade to V1.8.0 from all earlier versions.