using-declaration causes a multiple declaration of 'rl::memory_order'

206 views
Skip to first unread message

r...@vlinder.ca

unread,
Jul 31, 2014, 12:20:04 PM7/31/14
to rel...@googlegroups.com
Hello,

When including relacy_std while compiling with MSVS 2013, I'm geting this error:
3>C:\Users\Ronald\Source\Repos\project\relacy\relacy_2_4\relacy/relacy_std.hpp(21): error C2874: using-declaration causes a multiple declaration of 'rl::memory_order'
3>          c:\users\ronald\source\repos\project\relacy\relacy_2_4\relacy\memory_order.hpp(24) : see declaration of 'rl::memory_order'

I don't see why it's complaining though (I would *maybe* see a reason to say it's a duplicate definition of std::memory_order, but that's not what it's saying)

Any ideas/fixes?

Thanks,

Ronald

Ronald Landheer-Cieslak

unread,
Jul 31, 2014, 5:09:35 PM7/31/14
to rel...@googlegroups.com
commenting out the code removes the problem, so it looks like it's the compiler that's confused (should be a duplicate definition of std::memory_order and friends).
I don't use std::memory_order in my code, but I'm pretty sure that unless the Relacy version happens to use the same values, something is likely to go wrong if I just keep the code in comments - so I'm not proposing that as a fix.

Better ideas are more than welcome (I'm currently thinking a version-dependent #define to let the preprocessor think it's already seen the std version of the header, but that's avery ugly hack)

Dmitriy V'jukov

unread,
Aug 4, 2014, 7:29:29 AM8/4/14
to rel...@googlegroups.com
Hi Ronald,

I wrote Relacy when there were even no std::atomic implementations, so
some issues today are possible.

Perhaps we could omit the Relacy definition if <atomic> is already
included. Or just include <atomic> in the Relacy header to ensure that
the std definition is always available.
If you can prepare a patch with a test on top of
https://code.google.com/p/relacy/source/browse/
then I will submit it.
> --
> You received this message because you are subscribed to the Google Groups
> "Relacy Race Detector" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to relacy+un...@googlegroups.com.
> To post to this group, send email to rel...@googlegroups.com.
> Visit this group at http://groups.google.com/group/relacy.
> For more options, visit https://groups.google.com/d/optout.



--
Dmitry Vyukov

All about lockfree/waitfree algorithms, multicore, scalability,
parallel computing and related topics:
http://www.1024cores.net

Ronald Landheer-Cieslak

unread,
Aug 7, 2014, 12:22:28 PM8/7/14
to rel...@googlegroups.com
Hi Dmitry,

I don't see any way to include <atomic> and not run into a very wide range of problems: Relacy basically tries to spoof the std namespace for a lot of what it does, and most (if not all) of the examples and the test cases are written with the idea that Relacy lives in both the std and the rl namespaces. Including the real std namespace with all the atomics strappings and trying to mingle that with Relacy is asking for trouble.
Just to make sure I tried (to no avail).

I am now preparing a set of patches that take a different approach:
1) don't spoof std
2) convert all the examples and the test cases to use Relacy in the rl namespace
3) use cmake to generate sln files, including test cases (this has the advantage of having only one configuration file to generate projects for any version of the compilers you might use)
4) get it 

Ronald Landheer-Cieslak

unread,
Aug 7, 2014, 12:29:15 PM8/7/14
to rel...@googlegroups.com
darn keyboard..

anyways: 4) get it to work with all the (sane) compilers at my disposal (I have several versions of MSVC and several flavors of GCC on both x86 and x86_64, Linux and FreeBSD, and I think I have clang and maybe even icc lying around somewhere).
5) write a set of wrappers around std, so if not using Relacy to test, the rl:: namespace morphs into something that does "the real deal" (and ignores $)

I'm actually pretty far along with these patches already (the examples all compile without spoofing std and CMake generates the project files).

Step 5 will make it useful for applications other than testing (i.e. enable race detection in unit tests, use the same, unmodified code in production without race detection).

Questions/comments/suggestions are more than welcome,

Ronald

Dmitriy V'jukov

unread,
Aug 8, 2014, 4:12:08 AM8/8/14
to rel...@googlegroups.com
On Thu, Aug 7, 2014 at 8:29 PM, Ronald Landheer-Cieslak <r...@vlinder.ca> wrote:
> darn keyboard..
>
> anyways: 4) get it to work with all the (sane) compilers at my disposal (I
> have several versions of MSVC and several flavors of GCC on both x86 and
> x86_64, Linux and FreeBSD, and I think I have clang and maybe even icc lying
> around somewhere).
> 5) write a set of wrappers around std, so if not using Relacy to test, the
> rl:: namespace morphs into something that does "the real deal" (and ignores
> $)

How will the user code look like? Will it need to use std::atomic or
rl::atomic or RL(atomic)? Ideally, the user code uses std::atomic, but
that it turned into rl::atomic when relacy header is included.

Well, ideally Relacy uses the same instrumentation machinery as
ThreadSanitizer and just works transparently w/o any modifications to
code...

Ronald Landheer-Cieslak

unread,
Aug 8, 2014, 7:30:31 AM8/8/14
to rel...@googlegroups.com
Hi Dmitriy,


On Friday, August 8, 2014, Dmitriy V'jukov <dvy...@gmail.com> wrote:
On Thu, Aug 7, 2014 at 8:29 PM, Ronald Landheer-Cieslak <r...@vlinder.ca> wrote:
> darn keyboard..
>
> anyways: 4) get it to work with all the (sane) compilers at my disposal (I
> have several versions of MSVC and several flavors of GCC on both x86 and
> x86_64, Linux and FreeBSD, and I think I have clang and maybe even icc lying
> around somewhere).
> 5) write a set of wrappers around std, so if not using Relacy to test, the
> rl:: namespace morphs into something that does "the real deal" (and ignores
> $)

How will the user code look like? Will it need to use std::atomic or
rl::atomic or RL(atomic)? Ideally, the user code uses std::atomic, but
that it turned into rl::atomic when relacy header is included.

Well, ideally Relacy uses the same instrumentation machinery as
ThreadSanitizer and just works transparently w/o any modifications to
code...
What I'm currently looking at doing is user code that uses rl::atomic, so there are so few annotations with $ signs etc. but still very readable.
The idea is to make the testing machinery disappear at the flip of a switch, so rl::atomic becomes equivalent to std::atomic and the $ signs simply get ignored.

The problem with trying to let the user write code using std::atomic is that we don't own the std namespace - compiler and standard library vendors do. The code I was using that first ran into trouble didn't use std::atomic and didn't include <atomic>, but still got an error in relacy_std.hpp. I tried (briefly) to keep the idea of std::atomic transforming magically into rl::atomic, but that ran into all kinds of compiler errors *and* still required $ annotations in places where using the real std would frown.

ThreadSanitizer is nice, but takes a completely different approach.
If someone wanted to go "belt and suspenders" they'd write unit tests using relacy, using the rl namespace for all atomic stuff, and use rl::var<> for anything they think might be shared but needs to be locked. Then, when convinced their algorithms work, they'd still run the complete program with ThreadSanitizer a couple of thousand times (hoping real-life scheduling does similar  combination searching as the Relacy scheduler does).
Not sure which is the belt and which is the suspenders, but I think you see the idea.

[snip]

I currently have most of the examples working (one is broken because it tries to delete static thread-local data, one doesn't contain any code that wasn't commented out, all the others work).
Next step is to run it through the complete array of compilers I have at my disposal, before I write the non-testing wrapper classes.
If you want, I can post the patches I have so far.

rlc


--
-- 
Software for Embedded Industrial Devices
Software development & analysis
Vlinder Software: http://vlinder.ca

Ronald Landheer-Cieslak

unread,
Aug 10, 2014, 10:26:38 PM8/10/14
to rel...@googlegroups.com
Hi Dmitriy,

Would you have any objection to me splitting the test cases up into individual executables?
Some of the test cases are not compiling on all target platforms and the fact that the test cases are currently a monolithic executable is not helping.

Regards,

Ronald

Ronald Landheer-Cieslak

unread,
Aug 30, 2014, 5:45:30 PM8/30/14
to rel...@googlegroups.com
Hi Dmitriy,

As I haven't had a reply to this question, I haven't split the test cases up.

I haven't had much time to work on this for the last three weeks, but I thought I'd post what I have now. I moved to Git because I got frustrated with Mercurial, so I created a GitHub repository, here: https://github.com/VlinderSoftware/relacy

Some feed-back would be nice - I don't want to end up maintaining a fork.

The next step to what I was planning is to create wrappers around std in the rl namespace. I will not do that without feed-back, because I don't actually need it (I have my own wrappers around both Relacy and std, and platform-specific atomics when std isn't available).

Ronald
Reply all
Reply to author
Forward
0 new messages