...

hi all, especially release managers,

boost.lockfree is now in trunk and it passes the tests on most supported platforms. atm it includes a private copy of boost.atomic, which will be removed once boost.atomic is merged (helge wanted to do it quite soon)

actually it is merged now ;)

great to hear ... checking the specific commit, it seems that the integration into the boost infrastructure (doc/testfarm etc) is still missing ... please compare with r79196, the specific commit for boost.lockfree. thanks, tim

...

...

actually it is merged now ;)

great to hear ... checking the specific commit, it seems that the integration into the boost infrastructure (doc/testfarm etc) is still missing ... please compare with r79196, the specific commit for boost.lockfree.

thanks for the pointer, will fix it, and if you notice anything else, just write so I can fix it ASAP

trying to compile with the intel compiler gives me: ./boost/atomic/detail/cas64strong.hpp(24): error: class template "boost::atomics::detail::base_atomic" has already been defined class base_atomic<T, int, 8, Sign> { ^ ./boost/atomic/detail/cas64strong.hpp(148): error: class template "boost::atomics::detail::base_atomic" has already been defined class base_atomic<void *, void *, 8, Sign> { ^ ./boost/atomic/detail/cas64strong.hpp(243): error: class template "boost::atomics::detail::base_atomic" has already been defined class base_atomic<T *, void *, 8, Sign> { ^ ./boost/atomic/detail/cas64strong.hpp(340): error: class template "boost::atomics::detail::base_atomic" has already been defined class base_atomic<T, void, 8, Sign> { ^ also keep an eye on the test farm, they as that might show some issues on rather obscure compilers/platforms tim

On Tue, 10 Jul 2012, Tim Blechmann wrote:

hello helge,

...

...

great to hear ... checking the specific commit, it seems that the integration into the boost infrastructure (doc/testfarm etc) is still missing ... please compare with r79196, the specific commit for boost.lockfree.

thanks for the pointer, will fix it, and if you notice anything else, just write so I can fix it ASAP

i wonder, what is the current state of boost.atomic regarding interprocess communication?

if BOOST_ATOMIC_*_LOCK_FREE==2, then the corresponding data type is interprocess-safe (this behaviour is only recommended for std::atomic, but not guaranteed) as per the suggestion during review I have implemented a partially specialized template representing the *_LOCK_FREE macros to allow implementing an "interprocess_atomic" that is safe independent from the data type (as long as atomic_flag is safe, of course) -- this is however not in svn yet regards Helge

On Tue, 10 Jul 2012, Tim Blechmann wrote:

...

...

...

...

great to hear ... checking the specific commit, it seems that the integration into the boost infrastructure (doc/testfarm etc) is still missing ... please compare with r79196, the specific commit for boost.lockfree.

thanks for the pointer, will fix it, and if you notice anything else, just write so I can fix it ASAP

i wonder, what is the current state of boost.atomic regarding interprocess communication?

if BOOST_ATOMIC_*_LOCK_FREE==2, then the corresponding data type is interprocess-safe

i see ... do you have any plans to provide a metafunction or traits class, which provides this information at the level of the c++ language so that it can be used for template metaprogramming?

see below, yes -- and I agree that this is helpful to have in addition to macro definitions [...]

...

as per the suggestion during review I have implemented a partially specialized template representing the *_LOCK_FREE macros to allow implementing an "interprocess_atomic" that is safe independent from the data type (as long as atomic_flag is safe, of course)

according to the latest draft that i have on my machine, atomic_flag shall be atomic.

True, the "difficulty" for boost::atomic is that I have provided a fallback path that is using thread::mutex as a "last resort" internally if the implementation can find no platform support at all, and this means even "atomic_flag" will use a mutex (hence not be interprocess-safe) -- this is not ideal, but the alternative is to possibly fail compilation entirely on some "fringe" platforms even for intraprocess atomics. (Of course, compilation *must* fail entirely for interprocess in such a scenario). Disagree? Regards Helge

On 09/07/2012 19:49, Tim Blechmann wrote:

...

...

iac, the deadline for new libraries in 1.51 is today, but from my side, boost.lockfree could be included as it is now. however if the release managers consider it as too late, i'm don't have a problem with waiting for another release cycle ...

It feels a little late to me, we normally try to sort out documentation, inspect errors etc. before merging. But see what the other release managers think.

since boost.atomic is now in trunk, too, i prefer to wait for 1.52 to make use of boost.atomic instead of providing a private copy of it ... i think, that is much cleaner, despite delaying the release by another few months ...

If you're going with boost.atomic, (which I believe you should) then you'll definitely need to wait as it broke lockfree on MSVC 10. Thing no longer compile. KTC

On 09/07/2012 21:13, Tim Blechmann wrote:

...

...

...

...

iac, the deadline for new libraries in 1.51 is today, but from my side, boost.lockfree could be included as it is now. however if the release managers consider it as too late, i'm don't have a problem with waiting for another release cycle ...

It feels a little late to me, we normally try to sort out documentation, inspect errors etc. before merging. But see what the other release managers think.

since boost.atomic is now in trunk, too, i prefer to wait for 1.52 to make use of boost.atomic instead of providing a private copy of it ... i think, that is much cleaner, despite delaying the release by another few months ...

If you're going with boost.atomic, (which I believe you should) then you'll definitely need to wait as it broke lockfree on MSVC 10. Thing no longer compile.

can you post the compile error, so that helge can have a look?

See <http://www.ktchan.info/files/lockfree-r79392.log>. KTC

...

...

boost.lockfree is now in trunk and it passes the tests on most supported platforms. atm it includes a private copy of boost.atomic, which will be removed once boost.atomic is merged (helge wanted to do it quite soon) ... there are still some test failures on win32, but i think i found the reason and fixed the tests (btw it is rather time consuming to work with the test farm as the win32 tests are only run about once a week). It's doing better but "stack overflow"?

<http://www.boost.org/development/tests/trunk/developer/output/KTC-Win7x64_VC10x64-boost-bin-v2-libs-lockfree-test-queue_test-test-msvc-10-0-debug-address-model-64-threading-multi.html> <http://www.boost.org/development/tests/trunk/developer/output/KTC-Win7x64_VC10x64-boost-bin-v2-libs-lockfree-test-stack_test-test-msvc-10-0-debug-address-model-64-threading-multi.html>

same `stack overflow' that i've seen in some other win32 tests ... it seems that win32 does not like that to allocate large objects on the stack ... tim

I am posting this again in that the boot list indicated it needed subscription. ------- Jonathan, (redi at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>) Re: [Bug c++/53899] [C++0x] undefined reference to std::atomic<boost::lockfree::detail::tagged_ptr... I installed g++-4.7 and obtained a good improvement over the prior results with the following output boost_lockfree/libs/lockfree/test$ g++-4.7 -std=c++0x bench_3.cpp -o bench_3 In file included from /usr/include/boost/lockfree/detail/atomic.hpp:15:0, from ../../../boost/lockfree/fifo.hpp:26, from bench_3.cpp:1: /usr/include/c++/4.7/atomic: In instantiation of ‘struct std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>

’: /usr/include/boost/lockfree/detail/freelist.hpp:203:29: required from here /usr/include/c++/4.7/atomic:160:7: error: function ‘std::atomic<_Tp>::atomic() [with _Tp = boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>]’ defaulted on its first declaration with an exception-specification that differs from the implicit declaration ‘std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> ::atomic()’ /usr/include/c++/4.7/atomic: In instantiation of ‘struct std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::fifo<long int, boost::lockfree::caching_freelist_t, std::allocator<long int> ::node> >’: ../../../boost/lockfree/fifo.hpp:287:29: required from ‘class boost::lockfree::detail::fifo<long int, boost::lockfree::caching_freelist_t, std::allocator<long int> >’ ../../../boost/lockfree/fifo.hpp:315:7: required from ‘class boost::lockfree::fifo<long int>’ bench_3.cpp:18:5: required from here /usr/include/c++/4.7/atomic:160:7: error: function ‘std::atomic<_Tp>::atomic() [with _Tp = boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::fifo<long int, boost::lockfree::caching_freelist_t, std::allocator<long int> ::node>]’ defaulted on its first declaration with an exception-specification that differs from the implicit declaration ‘std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::fifo<long int, boost::lockfree::caching_freelist_t, std::allocator<long int> ::node> >::atomic()’

Tim Blechmann posted on the Boost list this morning he was doing final testing for the Boost 51 release. I will copy this to him in case he has an idea. My impression is that g++ -std=c++0x and boost lockfree are rather close. Neil -- View this message in context: http://boost.2283326.n4.nabble.com/lockfree-include-into-1-51-tp4632704p4632... Sent from the Boost - Dev mailing list archive at Nabble.com.

Tim Blechmann posted on the Boost list this morning he was doing final testing for the Boost 51 release. I will copy this to him in case he has an idea. My impression is that g++ -std=c++0x and boost lockfree are rather close.

afaict, the code you tested is the pre-review code, which has changed a bit ... from my latest tests, gcc-4.7 still misses a few features of the atomic<> implementation (iirc i got an undefined reference to a builtin the last time i've tried) tim

and made the following changes (obviously not what would be done in the distribution) to obtain a good compile using

why doesn't this compile for you out of the box? current trunk makes use of boost.atomic (again) and you have to tweak lockfree/detail/atomic.hpp to be able to use atomic<> as it is currently disabled for all platforms.

Changed 'BOOST_NOEXCEPT' to 'noexcept' in the three files where it occurred. There is a define for 'BOOST_NOEXCEPT' in boost/config/suffix.hpp but including it did not clear the compile error.

BOOST_NOEXCEPT should resolve to noexcept, if it is supported by the compiler. so no need to change this.

And commented

// BOOST_STATIC_ASSERT(has_capacity);

in queue.hpp for 'queue(void)'.

this static assert is there for a reason. but it should probably check if the queue is fixed-sized. let me double-check this. tim

...

...

...

...

...

boost.lockfree is now in trunk and it passes the tests on most supported platforms. atm it includes a private copy of boost.atomic, which will be removed once boost.atomic is merged (helge wanted to do it quite soon) ... there are still some test failures on win32, but i think i found the reason and fixed the tests (btw it is rather time consuming to work with the test farm as the win32 tests are only run about once a week). It's doing better but "stack overflow"?

<http://www.boost.org/development/tests/trunk/developer/output/KTC-Win7x64_VC10x64-boost-bin-v2-libs-lockfree-test-queue_test-test-msvc-10-0-debug-address-model-64-threading-multi.html> <http://www.boost.org/development/tests/trunk/developer/output/KTC-Win7x64_VC10x64-boost-bin-v2-libs-lockfree-test-stack_test-test-msvc-10-0-debug-address-model-64-threading-multi.html>

same `stack overflow' that i've seen in some other win32 tests ... it seems that win32 does not like that to allocate large objects on the stack ...

should be fixed

Fixed "stack test", but "queue test" still fail. Doesn't really say why though.

<http://www.boost.org/development/tests/trunk/developer/output/KTC-Win7x64_VC10x64-boost-bin-v2-libs-lockfree-test-queue_test-test-msvc-10-0-debug-address-model-64-threading-multi.html>

the queue test has three stress tests (like the stack) ... however the queue is more complex than the stack ... the output comes from these stress tests: threads created writer threads joined, waiting for readers reader threads joined threads created writer threads joined, waiting for readers reader threads joined threads created this suggests that either the third test case fails, or that that it gets killed at some point. just to confirm, do you have a timeout for the tests? thanks, tim

...

...

...

this suggests that either the third test case fails, or that that it gets killed at some point. just to confirm, do you have a timeout for the tests?

Standard regression timeout, which I think is 5 minutes. Just ran it outside of regression on its own and it passed, so does suggest it was timeout.

hm ... i must admit that this is rather odd: the same test runs in about 0.5 seconds on my sandy bridge i7 (the release build in 0.3 seconds).

does this patch somehow improve the performance of the testsuite?

Nope, noticeably slower. I gave up in the 8th minute. Pre-patch (r79385) queue_test ran in about 4 minutes-ish on my machine outside of regression, so would pass depending on what else is going on during regression.

i wonder, what kind of machine is this? if it runs a factor of 500 slower than on my machine, then the compiler is generating really slow code (or running in an interpreter), the windows scheduler does some very wrong decisions or something else must go really wrong. thanks, tim