Dear all, I have a few meta comments about the Lockfree review and reviews in general: 1. I know a lot of people read this list via gmane.org. A bug in gmane.org means that when a message is posted to more than one list - for example, a review announcement sent to this list and announce@ - then it appears only in one, and follow-ups are lost. So gmane.org readers will have missed most of this review. Of course a valid answer would be "they should fix it", but considering how few reviews have been written recently I think we should do everything possible to increase discussion. I don't know if review managers get a "how to run your review" document, but assuming that they do, I suggest adding "please post separate announcements to each list, not one message to all". 2. I think every candidate library should have an online copy of its documentation. Again, I think this should be on the review manager's checklist. Yes, you could say that people should be able to download and unzip and/or build their own copy of the docs, but again, we need more reviews and we need to remove as many obstacles (real or imagined) as possible. (In the last review I asked "Where are the online docs?" and it turned out that they were available but I had missed them; oops. If I have once again missed them, oops again.) 3. This has already been discussed to some extent, but why are we reviewing this before Boost.Atomic? I think Boost.Atomic is an urgently-required library. What can we all do to help it get submitted and accepted as soon as possible? Regards, Phil.
3. This has already been discussed to some extent, but why are we reviewing this before Boost.Atomic?
the review is part of my summer-of-code program, so it will need to be finished before mid of august. waiting for boost.atomic to be reviewed might defer the boost.lockfree review for undefined time.
I think Boost.Atomic is an urgently-required library. What can we all do to help it get submitted and accepted as soon as possible?
the original author is quite unresponsive. i haven't heard from him since early this year, and he did not repond to any emails i've sent him. imo, a few people should gather and adopt the library, because i fear that it has been orphaned ... then we would only need a review manager and a time slot. cheers, tim
on Thu Jul 21 2011, Tim Blechmann <tim-AT-klingt.org> wrote:
I think Boost.Atomic is an urgently-required library. What can we all do to help it get submitted and accepted as soon as possible?
the original author is quite unresponsive. i haven't heard from him since early this year, and he did not repond to any emails i've sent him.
imo, a few people should gather and adopt the library, because i fear that it has been orphaned ... then we would only need a review manager and a time slot.
And, let me reiterate: until that time, you can include this functionality in a detail namespace of Lockfree. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave, Dave Abrahams wrote:
on Thu Jul 21 2011, Tim Blechmann <tim-AT-klingt.org> wrote:
I think Boost.Atomic is an urgently-required library. What can we all do to help it get submitted and accepted as soon as possible?
the original author is quite unresponsive. i haven't heard from him since early this year, and he did not repond to any emails i've sent him.
imo, a few people should gather and adopt the library, because i fear that it has been orphaned ... then we would only need a review manager and a time slot.
And, let me reiterate: until that time, you can include this functionality in a detail namespace of Lockfree.
If Tim did that then we would need to review it now, right? (For correctness, anyway. Not necessarily for its interface. But that doesn't make much difference in practice, since the interface is supposed to be the std:: one.) Phil.
on Sun Jul 24 2011, "Phil Endecott" <spam_from_boost_dev-AT-chezphil.org> wrote:
If Tim did that then we would need to review it now, right?
Only its implementation, not its interface or documentation.
(For correctness, anyway. Not necessarily for its interface. But that doesn't make much difference in practice, since the interface is supposed to be the std:: one.)
yes. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave Abrahams wrote:
on Sun Jul 24 2011, "Phil Endecott" <spam_from_boost_dev-AT-chezphil.org> wrote:
If Tim did that then we would need to review it now, right?
Only its implementation, not its interface or documentation.
(For correctness, anyway. Not necessarily for its interface. But that doesn't make much difference in practice, since the interface is supposed to be the std:: one.)
yes.
Taking this to its logical conclusion, wouldn't that make a separate review of atomic un-necessary? I personally feel that both lockfree and atomic should be accepted in principle, but don't feel fully qualified to review either. I think the most important thing is that there be active maintainers for both libraries so that when issues come up they are fixed. More than a review, atomic needs a maintainer. Lockfree, I am already convinced, is in good hands. If the lockfree maintainer is willing to maintain atomic as an implementation detail, why not as a stand alone library? If so, let's accept both at once and put atomic on the offical list of boost libraries. Regards, Luke
If Tim did that then we would need to review it now, right?
Only its implementation, not its interface or documentation.
(For correctness, anyway. Not necessarily for its interface. But that doesn't make much difference in practice, since the interface is supposed to be the std:: one.)
yes.
Taking this to its logical conclusion, wouldn't that make a separate review of atomic un-necessary?
at least the documentation part will need to be reviewed. from my experience of two reviews, most of the review are about the docs, followed by the interface, followed by the implementation.
I personally feel that both lockfree and atomic should be accepted in principle, but don't feel fully qualified to review either.
talking about this, i would really encourage people to review the boost.lockfree code. up to now, there is only one (1) vote and the review will end on 28th. i somehow have the feeling that people either are on holiday or the boostcon presentations about lockfree data structures (`you need to be a genious to write lock-free code') scared away many potential reviewers. seeing that there are only three days left for the review, i somehow doubt that anyone will review boost.atomic. :/
I think the most important thing is that there be active maintainers for both libraries so that when issues come up they are fixed. More than a review, atomic needs a maintainer. Lockfree, I am already convinced, is in good hands. If the lockfree maintainer is willing to maintain atomic as an implementation detail, why not as a stand alone library? If so, let's accept both at once and put atomic on the offical list of boost libraries.
i would be willing to co-maintain boost.atomic, but i really don't want to do it alone. a few days ago, i posted a message to see if there are possible volunteers to help maintaining boost.atomic. unfortunately i got zero (0) replies. tim
On 7/26/2011 2:40 AM, Tim Blechmann wrote:
I think the most important thing is that there be active maintainers for both libraries so that when issues come up they are fixed. More than a review, atomic needs a maintainer. Lockfree, I am already convinced, is in good hands. If the lockfree maintainer is willing to maintain atomic as an implementation detail, why not as a stand alone library? If so, let's accept both at once and put atomic on the offical list of boost libraries.
i would be willing to co-maintain boost.atomic, but i really don't want to do it alone. a few days ago, i posted a message to see if there are possible volunteers to help maintaining boost.atomic. unfortunately i got zero (0) replies.
That's too bad. It seems reasonably stable now for my platforms (x86[_64] Windows/Linux), so hopefully not much maintenance will be necessary there. For more esoteric platforms, might it be reasonable to expect the users of those platforms to put forth some effort toward adding atomic support? -Matt
Matthew Chambers wrote:
On 7/26/2011 2:40 AM, Tim Blechmann wrote:
I think the most important thing is that there be active maintainers for both libraries so that when issues come up they are fixed. More than a review, atomic needs a maintainer. Lockfree, I am already convinced, is in good hands. If the lockfree maintainer is willing to maintain atomic as an implementation detail, why not as a stand alone library? If so, let's accept both at once and put atomic on the offical list of boost libraries.
i would be willing to co-maintain boost.atomic, but i really don't want to do it alone. a few days ago, i posted a message to see if there are possible volunteers to help maintaining boost.atomic. unfortunately i got zero (0) replies.
Tim, I must have missed that. I have volunteered a couple of times now. But see below.
That's too bad. It seems reasonably stable now for my platforms (x86[_64] Windows/Linux)
Matt, how have you measured the stability? One of my main concerns with Atomic is that it seems to lack any tests, so it is hard to know whether it is actually working correctly or not. (Doing the correct operation but non-atomically, or without the required memory barriers, would often appear to work perfectly.)
so hopefully not much maintenance will be necessary there. For more esoteric platforms, might it be reasonable to expect the users of those platforms to put forth some effort toward adding atomic support?
Yes, though you might be hard pressed to find any users other than Helge for PPC and Alpha. But: my suspicion is that it is now too late for Boost.Atomic to be useful. g++ already seems to have its own std::atomic implementation (since 4.4 apparently). With the impending ratification of C++0x we can surely expect Microsoft and LLVM to have their implementations ready soon (apparently LLVM says "The only major missing piece of C++'0x support [in libc++] is <atomic>". So by the time a group of replacement maintainers got their acts together, they/we might only be maintaining Boost.Atomic for the benefit of a few people who are unable to use newest compilers. That wouldn't motivate me much. Regards, Phil.
Phil Endecott wrote:
But: my suspicion is that it is now too late for Boost.Atomic to be useful. g++ already seems to have its own std::atomic implementation (since 4.4 apparently). With the impending ratification of C++0x we can surely expect Microsoft and LLVM to have their implementations ready soon (apparently LLVM says "The only major missing piece of C++'0x support [in libc++] is <atomic>". So by the time a group of replacement maintainers got their acts together, they/we might only be maintaining Boost.Atomic for the benefit of a few people who are unable to use newest compilers. That wouldn't motivate me much.
I disagree. The majority of C++ projects will continue to use older compilers for years after the new standard is ratified and fully implemented by all major compilers. I don't expect people will port their code to the new C++ lightly. Compiler version changes tend to be painful and infrequent in large projects. Just consider how many people continue to use MSVC7.1 and 8. Boost atomic will provide a way to write code that is portable between new and old compilers. Specifically, boost code that is portable between new and old compiler will be enabled, so it is critically important for boost itself to add the library exactly because of the new standard. Regards, Luke
i would be willing to co-maintain boost.atomic, but i really don't want to do it alone. a few days ago, i posted a message to see if there are possible volunteers to help maintaining boost.atomic. unfortunately i got zero (0) replies.
Tim, I must have missed that. I have volunteered a couple of times now. But see below.
cool!
That's too bad. It seems reasonably stable now for my platforms (x86[_64] Windows/Linux)
Matt, how have you measured the stability? One of my main concerns with Atomic is that it seems to lack any tests, so it is hard to know whether it is actually working correctly or not. (Doing the correct operation but non-atomically, or without the required memory barriers, would often appear to work perfectly.)
well, i am not sure, whether it can be tested for full correctness. i suppose all we can do is to compile-tests, for the rest we would have to review the code.
But: my suspicion is that it is now too late for Boost.Atomic to be useful. g++ already seems to have its own std::atomic implementation (since 4.4 apparently). With the impending ratification of C++0x we can surely expect Microsoft and LLVM to have their implementations ready soon (apparently LLVM says "The only major missing piece of C++'0x support [in libc++] is <atomic>". So by the time a group of replacement maintainers got their acts together, they/we might only be maintaining Boost.Atomic for the benefit of a few people who are unable to use newest compilers. That wouldn't motivate me much.
i would hope that it is to late for a boost.atomic, but at the moment it doesn't seem to be obsolete: * apple is afraid to ship any gcc newer than gcc-4.2 because of gpl-3 paranoia, so most system use gcc-4.2 or even worse, the llvm version of it. * gcc-4.6 (and probably earlier) cannot compile boost.lockfree with std::atomic i suspect, their implementation is still incomplete * the c++0x support of clang++ is rather limited. they basically ask you to install a patched version of libstdc++. and libc++ is listing <atomic> as the final remaining piece for quite some time :/ i cannot comment on the micro$oft side, but i regularly see workarounds for missing c99 features ... cheers, tim
Tim Blechmann wrote:
Matt, how have you measured the stability? One of my main concerns with Atomic is that it seems to lack any tests, so it is hard to know whether it is actually working correctly or not. (Doing the correct operation but non-atomically, or without the required memory barriers, would often appear to work perfectly.)
well, i am not sure, whether it can be tested for full correctness. i suppose all we can do is to compile-tests, for the rest we would have to review the code.
At the very least, you can e.g. run two threads that inc and dec a shared atomic variable and verify that you get the expected answer. I'm sure that someone with some experience in this area would have many more ideas.
* gcc-4.6 (and probably earlier) cannot compile boost.lockfree with std::atomic i suspect, their implementation is still incomplete
Can you tell us more about that? Perhaps it points to an issue with boost.lockfree that reviewers might be interested in. Regards, Phil.
Matt, how have you measured the stability? One of my main concerns with Atomic is that it seems to lack any tests, so it is hard to know whether it is actually working correctly or not. (Doing the correct operation but non-atomically, or without the required memory barriers, would often appear to work perfectly.)
well, i am not sure, whether it can be tested for full correctness. i suppose all we can do is to compile-tests, for the rest we would have to review the code.
At the very least, you can e.g. run two threads that inc and dec a shared atomic variable and verify that you get the expected answer. I'm sure that someone with some experience in this area would have many more ideas.
in this case, one will have atomic operations
* gcc-4.6 (and probably earlier) cannot compile boost.lockfree with std::atomic
i suspect, their implementation is still incomplete
Can you tell us more about that? Perhaps it points to an issue with boost.lockfree that reviewers might be interested in.
many undefined references to std::atomic members: queue.cpp:(.text+0x48): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> >::load(std::memory_order) const' queue.cpp:(.text+0x9f): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>
::compare_exchange_weak(boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>, std::memory_order)' queue.cpp:(.text+0xc4): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp:(.text+0xed): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> ::store(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>, std::memory_order)' queue.cpp:(.text+0x106): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp:(.text+0x11c): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp:(.text+0x135): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp:(.text+0x176): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> ::compare_exchange_strong(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>, std::memory_order)' queue.cpp:(.text+0x1af): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> ::compare_exchange_weak(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>, std::memory_order)' queue.cpp:(.text+0x1e5): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> ::compare_exchange_strong(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>, std::memory_order)' CMakeFiles/queue.dir/queue.cpp.o: In function `consumer()': queue.cpp:(.text+0x24e): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp:(.text+0x26c): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp:(.text+0x282): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp:(.text+0x29b): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp:(.text+0x2f8): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> ::compare_exchange_weak(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>, std::memory_order)' queue.cpp:(.text+0x31b): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> >::load(std::memory_order) const' queue.cpp:(.text+0x369): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> ::compare_exchange_weak(boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>, std::memory_order)' queue.cpp:(.text+0x3c4): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> ::compare_exchange_strong(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>, std::memory_order)' queue.cpp:(.text+0x3ea): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp:(.text+0x3fe): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp:(.text+0x415): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp:(.text+0x42c): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp:(.text+0x493): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> ::compare_exchange_weak(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>, std::memory_order)' queue.cpp:(.text+0x4b7): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> >::load(std::memory_order) const' queue.cpp:(.text+0x50f): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> ::compare_exchange_weak(boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>, std::memory_order)' queue.cpp:(.text+0x566): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> ::compare_exchange_strong(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>, std::memory_order)' CMakeFiles/queue.dir/queue.cpp.o: In function `main': queue.cpp:(.text.startup+0x39): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::is_lock_free() const' queue.cpp:(.text.startup+0xad4): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::is_lock_free() const' queue.cpp:(.text.startup+0xae6): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> >::is_lock_free() const' CMakeFiles/queue.dir/queue.cpp.o: In function `_GLOBAL__sub_I_producer_count': queue.cpp:(.text.startup+0x145f): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::store(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>, std::memory_order)' queue.cpp:(.text.startup+0x1478): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::store(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>, std::memory_order)' CMakeFiles/queue.dir/queue.cpp.o: In function `boost::lockfree::detail::freelist_stack<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node, false, std::allocator<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::~freelist_stack()': queue.cpp: (.text._ZN5boost8lockfree6detail14freelist_stackINS0_5queueIiNS_9parameter5void_ES5_E4nodeELb0ESaIS7_EED2Ev[_ZN5boost8lockfree6detail14freelist_stackINS0_5queueIiNS_9parameter5void_ES5_E4nodeELb0ESaIS7_EED5Ev]+0x16): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> >::operator boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>() const' CMakeFiles/queue.dir/queue.cpp.o: In function `boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::~queue()': queue.cpp: (.text._ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED2Ev[_ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED5Ev]+0x23): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp: (.text._ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED2Ev[_ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED5Ev]+0x36): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp: (.text._ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED2Ev[_ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED5Ev]+0x54): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp: (.text._ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED2Ev[_ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED5Ev]+0xab): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::store(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>, std::memory_order)' queue.cpp: (.text._ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED2Ev[_ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED5Ev]+0xbf): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> ::load(std::memory_order) const' queue.cpp: (.text._ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED2Ev[_ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED5Ev]+0x10f): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> ::store(boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>, std::memory_order)' queue.cpp: (.text._ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED2Ev[_ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED5Ev]+0x148): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::store(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node>, std::memory_order)' queue.cpp: (.text._ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED2Ev[_ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED5Ev]+0x15a): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::load(std::memory_order) const' queue.cpp: (.text._ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED2Ev[_ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED5Ev]+0x17d): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> ::load(std::memory_order) const' queue.cpp: (.text._ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED2Ev[_ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED5Ev]+0x1dd): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> ::compare_exchange_weak(boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>, std::memory_order)' queue.cpp: (.text._ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED2Ev[_ZN5boost8lockfree5queueIiNS_9parameter5void_ES3_ED5Ev]+0x1f8): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> >::operator boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>() const' CMakeFiles/queue.dir/queue.cpp.o: In function `boost::lockfree::detail::freelist_stack<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node, false, std::allocator<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::reserve_unsafe(unsigned long)': queue.cpp: (.text._ZN5boost8lockfree6detail14freelist_stackINS0_5queueIiNS_9parameter5void_ES5_E4nodeELb0ESaIS7_EE14reserve_unsafeEm[boost::lockfree::detail::freelist_stack<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node, false, std::allocator<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::reserve_unsafe(unsigned long)]+0x42): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> >::load(std::memory_order) const' queue.cpp: (.text._ZN5boost8lockfree6detail14freelist_stackINS0_5queueIiNS_9parameter5void_ES5_E4nodeELb0ESaIS7_EE14reserve_unsafeEm[boost::lockfree::detail::freelist_stack<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node, false, std::allocator<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::reserve_unsafe(unsigned long)]+0x86): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> ::store(boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>, std::memory_order)' CMakeFiles/queue.dir/queue.cpp.o: In function `boost::lockfree::detail::freelist_stack<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node, false, std::allocator<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::allocate()': queue.cpp: (.text._ZN5boost8lockfree6detail14freelist_stackINS0_5queueIiNS_9parameter5void_ES5_E4nodeELb0ESaIS7_EE8allocateEv[boost::lockfree::detail::freelist_stack<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node, false, std::allocator<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::allocate()]+0x1f): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> >::load(std::memory_order) const' queue.cpp: (.text._ZN5boost8lockfree6detail14freelist_stackINS0_5queueIiNS_9parameter5void_ES5_E4nodeELb0ESaIS7_EE8allocateEv[boost::lockfree::detail::freelist_stack<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node, false, std::allocator<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_>::node> >::allocate()]+0x66): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> ::compare_exchange_weak(boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node>, std::memory_order)'
cheers, tim
Tim Blechmann wrote:
* gcc-4.6 (and probably earlier) cannot compile boost.lockfree with std::atomic
i suspect, their implementation is still incomplete
Can you tell us more about that? Perhaps it points to an issue with boost.lockfree that reviewers might be interested in.
many undefined references to std::atomic members:
queue.cpp:(.text+0x48): undefined reference to `std::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_node> >::load(std::memory_order) const'
Right, yes, see e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49445 ; it's incomplete. Regards, Phil.
On 26.07.2011 19:23, Tim Blechmann wrote:
i would hope that it is to late for a boost.atomic, but at the moment it doesn't seem to be obsolete:
* the c++0x support of clang++ is rather limited. they basically ask you to install a patched version of libstdc++. The patch is just to work around GCC 4.4's broken libstdc++ (it was written to a draft version of rvalue references). and libc++ is listing<atomic> as the final remaining piece for quite some time :/
i cannot comment on the micro$oft side, but i regularly see workarounds for missing c99 features ...
VS2010 doesn't have any support for <atomic>, but unlike C99, they actually plan to support C++0x. Sebastian
Matthew Chambers wrote:
That's too bad. It seems reasonably stable now for my platforms (x86[_64] Windows/Linux)
Matt, how have you measured the stability? One of my main concerns with Atomic is that it seems to lack any tests, so it is hard to know whether it is actually working correctly or not. (Doing the correct operation but non-atomically, or without the required memory barriers, would often appear to work perfectly.) We use fifo/queue in our command-line multithreaded analysis software. My measure of stability is
On 7/26/2011 11:54 AM, Phil Endecott wrote: that we don't get any mysterious crashes or aberrant results compared to when we used lock-based synchronization. :) Like any thread-safety issue, it's practically impossible to prove something is correct through testing. But you make a good point that Boost.Atmoic should have some tests that at least try to stress its correctness.
But: my suspicion is that it is now too late for Boost.Atomic to be useful. g++ already seems to have its own std::atomic implementation (since 4.4 apparently). With the impending ratification of C++0x we can surely expect Microsoft and LLVM to have their implementations ready soon (apparently LLVM says "The only major missing piece of C++'0x support [in libc++] is <atomic>". So by the time a group of replacement maintainers got their acts together, they/we might only be maintaining Boost.Atomic for the benefit of a few people who are unable to use newest compilers. That wouldn't motivate me much. I too disagree with this. It will be many years before many (important) projects even consider moving to C++1x. And as with many features (regex, filesystem, thread, etc.), having C++1x features in boost that work with old compilers is a great way to play with them and wet feet without making a big leap.
-Matt
On Jul 25, 2011, at 6:09 PM, Simonson, Lucanus J wrote:
I think the most important thing is that there be active maintainers for both libraries so that when issues come up they are fixed.
+1
More than a review, atomic needs a maintainer. Lockfree, I am already convinced, is in good hands. If the lockfree maintainer is willing to maintain atomic as an implementation detail, why not as a stand alone library?
Well, IMO the difference would be, if Tim includes it as a detail of his library, then he's only claiming that as much works as is used by Lockfree. BTW, are we talking about lockfree::detail::atomic or lockfree::atomic? For the same reason of not being quite ready for review, my mpl_graph is currently included in msm as msm::mpl_graph, which I suppose means that Christophe claims that it's working well enough for him. Of course I am still its maintainer, so that's a little different.
on Mon Jul 25 2011, "Simonson, Lucanus J" <lucanus.j.simonson-AT-intel.com> wrote:
Dave Abrahams wrote:
on Sun Jul 24 2011, "Phil Endecott" <spam_from_boost_dev-AT-chezphil.org> wrote:
If Tim did that then we would need to review it now, right?
Only its implementation, not its interface or documentation.
(For correctness, anyway. Not necessarily for its interface. But that doesn't make much difference in practice, since the interface is supposed to be the std:: one.)
yes.
Taking this to its logical conclusion, wouldn't that make a separate review of atomic un-necessary?
Not if it were to become a first class, outside-of-detail, Boost library. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
I have a few meta comments about the Lockfree review and reviews in general:
Sorry for the late reply, I missed this mail initially.
1. I know a lot of people read this list via gmane.org. A bug in gmane.org means that when a message is posted to more than one list - for example, a review announcement sent to this list and announce@ - then it appears only in one, and follow-ups are lost. So gmane.org readers will have missed most of this review. Of course a valid answer would be "they should fix it", but considering how few reviews have been written recently I think we should do everything possible to increase discussion. I don't know if review managers get a "how to run your review" document, but assuming that they do, I suggest adding "please post separate announcements to each list, not one message to all".
I was not aware of this. Is that 'documented' somewhere in the review manager related pages?
2. I think every candidate library should have an online copy of its documentation. Again, I think this should be on the review manager's checklist. Yes, you could say that people should be able to download and unzip and/or build their own copy of the docs, but again, we need more reviews and we need to remove as many obstacles (real or imagined) as possible. (In the last review I asked "Where are the online docs?" and it turned out that they were available but I had missed them; oops. If I have once again missed them, oops again.)
The way reviews have been cast so far, this was not a strict requirement, even if most of the authors provided such online docs. Anyways, Tim provided his docs online, AFAIK (in addition to the docs in the downloadable archive): http://tim.klingt.org/boost_lockfree/.
3. This has already been discussed to some extent, but why are we reviewing this before Boost.Atomic? I think Boost.Atomic is an urgently- required library. What can we all do to help it get submitted and accepted as soon as possible?
Tim already answered that one, I believe. Regards Hartmut --------------- http://boost-spirit.com
on Thu Jul 21 2011, "Phil Endecott" <spam_from_boost_dev-AT-chezphil.org> wrote:
2. I think every candidate library should have an online copy of its documentation. Again, I think this should be on the review manager's checklist.
+1 -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (8)
-
Dave Abrahams -
Gordon Woodhull -
Hartmut Kaiser -
Matthew Chambers -
Phil Endecott -
Sebastian Redl -
Simonson, Lucanus J -
Tim Blechmann