[1.53] request to merge lockfree (c++11 only)
hi all, i'm not sure about the state of atomic, as the original author hardly reacts on emails and atm, i don't have the time to adopt it ... i'd therefore request permission to merge boost.lockfree into release, depending on std::atomic<>. this means, that it will require gcc-4.8 or msvc 2012 in c++11 mode to compile it (not sure about clang++, as their c++11 support under linux is pretty broken). the architecture of boost.lockfree is modular, so once boost.atomic is merged, it is trivial to use it again and allow use of the library with pre-c++11 compilers ... this is far from ideal, but boost.atomic has been blocking the release of boost.lockfree for a long time and it doesn't look like that it will be available before std::atomic<> is widely supported ... thoughts? tim
On Fri, Nov 16, 2012 at 3:08 PM, Tim Blechmann <tim@klingt.org> wrote:
hi all,
i'm not sure about the state of atomic, as the original author hardly reacts on emails and atm, i don't have the time to adopt it ...
Are you aware of the blockers that prevent Boost.Atomic from being merged to release? Perhaps there are minor problems and we could help the author to resolve them and merge Boost.Atomic ourselves.
i'd therefore request permission to merge boost.lockfree into release, depending on std::atomic<>. this means, that it will require gcc-4.8 or msvc 2012 in c++11 mode to compile it (not sure about clang++, as their c++11 support under linux is pretty broken).
Relying on an unreleased version of gcc looks nearly unacceptable to me. I know previous versions did not support atomic structs but this is hardly the reason to ignore atomic integers that were supported since gcc 4.4. Can Boost.Lockfree be adopted to use integer atomics?
i'm not sure about the state of atomic, as the original author hardly reacts on emails and atm, i don't have the time to adopt it ...
Are you aware of the blockers that prevent Boost.Atomic from being merged to release? Perhaps there are minor problems and we could help the author to resolve them and merge Boost.Atomic ourselves.
i'm not aware of any further issues with boost.atomic. most of the issues that have been raised during the review have been resolved. the only remaining thing is the fallback for shared-memory, but according to the standard, the behavior is not really defined ... and helge originally wanted to provide a version that supports shared memory to be included into boost.interprocess ... for 1.52 i considered adopting boost.atomic, but ran out of time and atm, i don't have the resources to work on this, either ... but if you'd volunteer to help, it would be really great!
i'd therefore request permission to merge boost.lockfree into release, depending on std::atomic<>. this means, that it will require gcc-4.8 or msvc 2012 in c++11 mode to compile it (not sure about clang++, as their c++11 support under linux is pretty broken).
Relying on an unreleased version of gcc looks nearly unacceptable to me. I know previous versions did not support atomic structs but this is hardly the reason to ignore atomic integers that were supported since gcc 4.4. Can Boost.Lockfree be adopted to use integer atomics?
possible, but will require some changes to boost.lockfree, that i'd rather avoid if possible ... tim
On Fri, Nov 16, 2012 at 3:39 PM, Tim Blechmann <tim@klingt.org> wrote:
i'm not sure about the state of atomic, as the original author hardly reacts on emails and atm, i don't have the time to adopt it ...
Are you aware of the blockers that prevent Boost.Atomic from being merged to release? Perhaps there are minor problems and we could help the author to resolve them and merge Boost.Atomic ourselves.
i'm not aware of any further issues with boost.atomic. most of the issues that have been raised during the review have been resolved. the only remaining thing is the fallback for shared-memory, but according to the standard, the behavior is not really defined ... and helge originally wanted to provide a version that supports shared memory to be included into boost.interprocess ...
Interprocess atomics are not the blocker for Boost.Atomic, it can be added later. Aside from Boost.Test-related errors and tester issues, tests look green in trunk (although I didn't check each one of them). So unless there is something non-obvious (Helge, could you confirm this?), I'd simply merge Boost.Atomic to release as it is.
for 1.52 i considered adopting boost.atomic, but ran out of time and atm, i don't have the resources to work on this, either ... but if you'd volunteer to help, it would be really great!
I thought Boost.Lockfree already uses Boost.Atomic, doesn't it? What needs to be changed?
i'm not sure about the state of atomic, as the original author hardly reacts on emails and atm, i don't have the time to adopt it ...
Are you aware of the blockers that prevent Boost.Atomic from being merged to release? Perhaps there are minor problems and we could help the author to resolve them and merge Boost.Atomic ourselves.
i'm not aware of any further issues with boost.atomic. most of the issues that have been raised during the review have been resolved. the only remaining thing is the fallback for shared-memory, but according to the standard, the behavior is not really defined ... and helge originally wanted to provide a version that supports shared memory to be included into boost.interprocess ...
Interprocess atomics are not the blocker for Boost.Atomic, it can be added later. Aside from Boost.Test-related errors and tester issues, tests look green in trunk (although I didn't check each one of them). So unless there is something non-obvious (Helge, could you confirm this?), I'd simply merge Boost.Atomic to release as it is.
would be fine with me (me as in `review manager')
for 1.52 i considered adopting boost.atomic, but ran out of time and atm, i don't have the resources to work on this, either ... but if you'd volunteer to help, it would be really great!
I thought Boost.Lockfree already uses Boost.Atomic, doesn't it? What needs to be changed?
boost.lockfree uses atomic<>, which is boost::atomic or std::atomic (if available). but it instantiates it with a struct, so it does not compile with g++ older than 4.8 ... tim
Le 16/11/12 13:25, Andrey Semashev a écrit :
i'm not sure about the state of atomic, as the original author hardly reacts on emails and atm, i don't have the time to adopt it ... Are you aware of the blockers that prevent Boost.Atomic from being merged to release? Perhaps there are minor problems and we could help the author to resolve them and merge Boost.Atomic ourselves. i'm not aware of any further issues with boost.atomic. most of the issues that have been raised during the review have been resolved. the only remaining thing is the fallback for shared-memory, but according to the standard, the behavior is not really defined ... and helge originally wanted to provide a version that supports shared memory to be included into boost.interprocess ... Interprocess atomics are not the blocker for Boost.Atomic, it can be added later. Aside from Boost.Test-related errors and tester issues, tests look green in trunk (although I didn't check each one of them). So unless there is something non-obvious (Helge, could you confirm
On Fri, Nov 16, 2012 at 3:39 PM, Tim Blechmann <tim@klingt.org> wrote: this?), I'd simply merge Boost.Atomic to release as it is.
I think it is up to the author to merge to release when he is ready. Releasing a library is something that could involve a lot of maintenance effort and should be done only when the author/maintainer is ready to follow-up. Best, Vicente
i'm not sure about the state of atomic, as the original author hardly reacts on emails and atm, i don't have the time to adopt it ...
i'd therefore request permission to merge boost.lockfree into release, depending on std::atomic<>. this means, that it will require gcc-4.8 or msvc 2012 in c++11 mode to compile it (not sure about clang++, as their c++11 support under linux is pretty broken).
the architecture of boost.lockfree is modular, so once boost.atomic is merged, it is trivial to use it again and allow use of the library with pre-c++11 compilers ... this is far from ideal, but boost.atomic has been blocking the release of boost.lockfree for a long time and it doesn't look like that it will be available before std::atomic<> is widely supported ...
I'd ask to leave it configurable as some people (like me) rely on using the non-released boost.atomics library for older compilers (shipped with our stuff) and we would like to avoid having to mix boost::atomics and std::atomics just to be able to use boost.lockfree as well. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
the architecture of boost.lockfree is modular, so once boost.atomic is merged, it is trivial to use it again and allow use of the library with pre-c++11 compilers ... this is far from ideal, but boost.atomic has been blocking the release of boost.lockfree for a long time and it doesn't look like that it will be available before std::atomic<> is widely supported ...
I'd ask to leave it configurable as some people (like me) rely on using the non-released boost.atomics library for older compilers (shipped with our stuff) and we would like to avoid having to mix boost::atomics and std::atomics just to be able to use boost.lockfree as well.
i'll probably introduce a preprocessor symbol like BOOST_LOCKFREE_USE_BOOST_ATOMIC that could be used, if the user provides boost.atomic manually ... tim
On 16 November 2012 11:08, Tim Blechmann <tim@klingt.org> wrote:
i'd therefore request permission to merge boost.lockfree into release, depending on std::atomic<>. this means, that it will require gcc-4.8 or msvc 2012 in c++11 mode to compile it (not sure about clang++, as their c++11 support under linux is pretty broken).
I think we should try to release lockfree in this release cycle. A library that has passed review shouldn't be delayed indefinitely for circumstances outside of the author's control, and releasing it might be the impetus for someone working on atomic. I haven't checked with the other release managers, but IIRC the past consensus was that it should be released. Now the box ticking... Documentation looks okay, I'll have a quick read later. I'll add a redirect file at 'libs/lockfree/index.html'. You need to add the library to 'libs/libraries.htm' in the alphabetic and category lists. Categories are up to you, but I'd expect: containers, concurrent and maybe data structures. Link to 'libs/lockfree/index.html' - not 'doc/html/whatever'. Unfortunately the online inspect report is out of date, so I ran it locally and got this for lockfree: |lockfree| boost/lockfree/detail/freelist.hpp: Boost macro deprecated in 1.51: BOOST_NO_DEFAULTED_FUNCTIONS boost/lockfree/detail/tagged_ptr_dcas.hpp: Boost macro deprecated in 1.51: BOOST_NO_DEFAULTED_FUNCTIONS boost/lockfree/detail/tagged_ptr_ptrcompression.hpp: Boost macro deprecated in 1.51: BOOST_NO_DEFAULTED_FUNCTIONS It should be 'BOOST_NO_CXX11_DEFAULTED_FUNCTIONS'. Since we know the library isn't going to work on any of the currently tested platforms, checking the test results seems pointless. There are a lot of failures, but if they're down to atomic not being ready, then I guess they're acceptable? I'd normally suggest marking up the failing test results in status/explicit-failures-markup.xml, but that might be counter-productive if they could be fixed in atomic. Failures due to boost dependencies are a real pain. I think the best I can do is install gcc 4.8 on my computer and give it a go. And ask for volunteers to do the same for the new Visual C++ and clang.
hi daniel,
You need to add the library to 'libs/libraries.htm' in the alphabetic and category lists. Categories are up to you, but I'd expect: containers, concurrent and maybe data structures. Link to 'libs/lockfree/index.html' - not 'doc/html/whatever'.
done
Unfortunately the online inspect report is out of date, so I ran it locally and got this for lockfree:
|lockfree| boost/lockfree/detail/freelist.hpp: Boost macro deprecated in 1.51: BOOST_NO_DEFAULTED_FUNCTIONS boost/lockfree/detail/tagged_ptr_dcas.hpp: Boost macro deprecated in 1.51: BOOST_NO_DEFAULTED_FUNCTIONS boost/lockfree/detail/tagged_ptr_ptrcompression.hpp: Boost macro deprecated in 1.51: BOOST_NO_DEFAULTED_FUNCTIONS
done
Since we know the library isn't going to work on any of the currently tested platforms, checking the test results seems pointless. There are a lot of failures, but if they're down to atomic not being ready, then I guess they're acceptable? I'd normally suggest marking up the failing test results in status/explicit-failures-markup.xml, but that might be counter-productive if they could be fixed in atomic. Failures due to boost dependencies are a real pain.
for the mingw/interprocess related failures, i might need some help: there is a linking failure, but i don't know what to link to. cheers, tim
Le 17/11/12 12:36, Tim Blechmann a écrit :
hi daniel,
You need to add the library to 'libs/libraries.htm' in the alphabetic and category lists. Categories are up to you, but I'd expect: containers, concurrent and maybe data structures. Link to 'libs/lockfree/index.html' - not 'doc/html/whatever'. done
Unfortunately the online inspect report is out of date, so I ran it locally and got this for lockfree:
|lockfree| boost/lockfree/detail/freelist.hpp: Boost macro deprecated in 1.51: BOOST_NO_DEFAULTED_FUNCTIONS boost/lockfree/detail/tagged_ptr_dcas.hpp: Boost macro deprecated in 1.51: BOOST_NO_DEFAULTED_FUNCTIONS boost/lockfree/detail/tagged_ptr_ptrcompression.hpp: Boost macro deprecated in 1.51: BOOST_NO_DEFAULTED_FUNCTIONS done
Since we know the library isn't going to work on any of the currently tested platforms, checking the test results seems pointless. There are a lot of failures, but if they're down to atomic not being ready, then I guess they're acceptable? I'd normally suggest marking up the failing test results in status/explicit-failures-markup.xml, but that might be counter-productive if they could be fixed in atomic. Failures due to boost dependencies are a real pain. for the mingw/interprocess related failures, i might need some help: there is a linking failure, but i don't know what to link to.
I have no idea. Maybe you could request help from Ion. There is a test that is failing on all the Windows testers spsc_queue_test. Have you an idea of what is going wrong? Best, Vicente
Since we know the library isn't going to work on any of the currently tested platforms, checking the test results seems pointless. There are a lot of failures, but if they're down to atomic not being ready, then I guess they're acceptable? I'd normally suggest marking up the failing test results in status/explicit-failures-markup.xml, but that might be counter-productive if they could be fixed in atomic. Failures due to boost dependencies are a real pain. for the mingw/interprocess related failures, i might need some help: there is a linking failure, but i don't know what to link to.
I have no idea. Maybe you could request help from Ion.
There is a test that is failing on all the Windows testers spsc_queue_test. Have you an idea of what is going wrong?
have fixed this ... seems that windows doesn't like stack-allocation of larger objects ... tim
Le 17/11/12 13:38, Tim Blechmann a écrit :
Since we know the library isn't going to work on any of the currently tested platforms, checking the test results seems pointless. There are a lot of failures, but if they're down to atomic not being ready, then I guess they're acceptable? I'd normally suggest marking up the failing test results in status/explicit-failures-markup.xml, but that might be counter-productive if they could be fixed in atomic. Failures due to boost dependencies are a real pain. for the mingw/interprocess related failures, i might need some help: there is a linking failure, but i don't know what to link to.
I have no idea. Maybe you could request help from Ion.
There is a test that is failing on all the Windows testers spsc_queue_test. Have you an idea of what is going wrong? have fixed this ... seems that windows doesn't like stack-allocation of larger objects ...
thanks, Vicente
Le 16/11/12 12:08, Tim Blechmann a écrit :
hi all,
i'm not sure about the state of atomic, as the original author hardly reacts on emails and atm, i don't have the time to adopt it ...
i'd therefore request permission to merge boost.lockfree into release, depending on std::atomic<>. this means, that it will require gcc-4.8 or msvc 2012 in c++11 mode to compile it (not sure about clang++, as their c++11 support under linux is pretty broken).
the architecture of boost.lockfree is modular, so once boost.atomic is merged, it is trivial to use it again and allow use of the library with pre-c++11 compilers ... this is far from ideal, but boost.atomic has been blocking the release of boost.lockfree for a long time and it doesn't look like that it will be available before std::atomic<> is widely supported ...
I don't see any problem as soon as the interface is not changed. Of course the documentation should describe the limitations and with which compilers/libraries the library works. Best, Vicente
participants (5)
-
Andrey Semashev -
Daniel James -
Hartmut Kaiser -
Tim Blechmann -
Vicente J. Botet Escriba