[release] permission to merge atomic and lockfree
hi all, apparently boost.atomic has been abandoned. i must admit, i'm very disappointed that the original author did hardly reacted neither on-list nor off-list. furthermore, it is blocking the release of boost.lockfree, so i'm volunteering to maintain this library. i'd rather see helge bahmann coming back and taking over responsibility for his code, but frankly, i lost all hopes that this is going to happen. iac, i'd like to get permission from the release managers to merge both atomic and lockfree to the release branch. thanks, tim
Greetings,
furthermore, it is blocking the release of boost.lockfree, so i'm volunteering to maintain this library. i'd rather see helge bahmann coming back and taking over responsibility for his code, but frankly, i lost all hopes that this is going to happen.
iac, i'd like to get permission from the release managers to merge both atomic and lockfree to the release branch.
It would be good news if that was accepted; the lack of atomic operations in boost[.thread] is quite annoying when performance matters. Regards, Étienne This message and any attachments are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. If you have received this message by mistake, please notify us immediately. ATEME decline all responsibility for this message if it has been altered, deformed, falsified or even edited or disseminated without authorization.
On 12/6/2012 3:49 AM, Tim Blechmann wrote:
hi all,
apparently boost.atomic has been abandoned. i must admit, i'm very disappointed that the original author did hardly reacted neither on-list nor off-list.
furthermore, it is blocking the release of boost.lockfree, so i'm volunteering to maintain this library. i'd rather see helge bahmann coming back and taking over responsibility for his code, but frankly, i lost all hopes that this is going to happen.
iac, i'd like to get permission from the release managers to merge both atomic and lockfree to the release branch.
Thanks, Tim. I haven't been tracking the Boost.Atomic saga too carefully. Is it ready to be merged to release? Forgive me if this has been discussed already. -- Eric Niebler BoostPro Computing http://www.boostpro.com
apparently boost.atomic has been abandoned. i must admit, i'm very disappointed that the original author did hardly reacted neither on-list nor off-list.
furthermore, it is blocking the release of boost.lockfree, so i'm volunteering to maintain this library. i'd rather see helge bahmann coming back and taking over responsibility for his code, but frankly, i lost all hopes that this is going to happen.
iac, i'd like to get permission from the release managers to merge both atomic and lockfree to the release branch.
Thanks, Tim. I haven't been tracking the Boost.Atomic saga too carefully. Is it ready to be merged to release? Forgive me if this has been discussed already.
i (as in review manager) don't see any showstoppers ... afaict, the only point that is somehow missing is blocking fallback support for shared memory in the case that an atomic object is not lockfree. helge originally intended to provide a separate implementation for boost.interprocess, but well ... at that time he was at least reacting to emails :/ however that is not crucial, as the standard specifies the behavior in this case as `implementation defined'. tim
On 6 December 2012 11:49, Tim Blechmann <tim@klingt.org> wrote:
hi all,
apparently boost.atomic has been abandoned. i must admit, i'm very disappointed that the original author did hardly reacted neither on-list nor off-list.
furthermore, it is blocking the release of boost.lockfree, so i'm volunteering to maintain this library.
I thought we'd agreed that lockfree could be initially released for just compilers with native support.
i'd rather see helge bahmann coming back and taking over responsibility for his code, but frankly, i lost all hopes that this is going to happen.
iac, i'd like to get permission from the release managers to merge both atomic and lockfree to the release branch.
As far as I'm concerned, lockfree is okay for merging. Could do with marking up expected failures. I'll get back to you about atomic. Although it needs to have the usual things dealt with (libs/libraries, libs/maintainers, libs/atomic/index.html, marking up errors).
On 7 December 2012 16:17, Daniel James <dnljms@gmail.com> wrote:
I'll get back to you about atomic. Although it needs to have the usual things dealt with (libs/libraries, libs/maintainers, libs/atomic/index.html, marking up errors).
To avoid rushing atomic into release, it can have an extra week to get things ready.
On Fri, Dec 7, 2012 at 8:53 PM, Daniel James <dnljms@gmail.com> wrote:
On 7 December 2012 16:17, Daniel James <dnljms@gmail.com> wrote:
I'll get back to you about atomic. Although it needs to have the usual things dealt with (libs/libraries, libs/maintainers, libs/atomic/index.html, marking up errors).
To avoid rushing atomic into release, it can have an extra week to get things ready.
Umm, so is atomic allowed to be merged? If so, are there other things (aside from what you have listed) that need to be done before the merge? I volunteered to help with the merge off-list, so I'd like to know when I'm good to go.
hi andrey,
I'll get back to you about atomic. Although it needs to have the usual things dealt with (libs/libraries, libs/maintainers, libs/atomic/index.html, marking up errors).
To avoid rushing atomic into release, it can have an extra week to get things ready.
Umm, so is atomic allowed to be merged? If so, are there other things (aside from what you have listed) that need to be done before the merge?
atm, there are two problems that i see: * there are some test failures for msvc on 64bit platform. afaict, it is mainly a configuration issue. * the cray testfarm machine reports some errors, which are most likely related to having a notion of `local' and `global' atomics. i suppose, this kind of machines won't be supported for now ... apart from that, i think it is ready to merge, once the release managers grant the permission ... tim btw, thanks for helping with the merge!
On 10 December 2012 13:24, Tim Blechmann <tim@klingt.org> wrote:
atm, there are two problems that i see:
* there are some test failures for msvc on 64bit platform. afaict, it is mainly a configuration issue.
I don't know enough about this, so I'll leave it up to you.
* the cray testfarm machine reports some errors, which are most likely related to having a notion of `local' and `global' atomics. i suppose, this kind of machines won't be supported for now ...
Unless I'm missing something, it's all green now. There's still a lockfree failure. Either way, Cray support isn't essential.
apart from that, i think it is ready to merge, once the release managers grant the permission ...
Yes, when you feel it's appropriate.
* there are some test failures for msvc on 64bit platform. afaict, it is mainly a configuration issue.
I don't know enough about this, so I'll leave it up to you.
actually, i might need some help from someone who has access to msvc ...
* the cray testfarm machine reports some errors, which are most likely related to having a notion of `local' and `global' atomics. i suppose, this kind of machines won't be supported for now ...
Unless I'm missing something, it's all green now. There's still a lockfree failure. Either way, Cray support isn't essential.
well, i'm not too sure, how accurate the tests on teeks99-3-win7-64on64 are ... for boost.heap, it reports an issue, that i've already fixed some time ago ... the pgi compiler reports a several failures, too, but i'm also quite sure that it is a problem of that compiler (and being a test at sandia, maybe also a hpc machine, that will need some special care) in general, it is hard to tell, if the problems are issues with boost.atomic or with boost.lockfree ...
apart from that, i think it is ready to merge, once the release managers grant the permission ...
Yes, when you feel it's appropriate.
thanks! tim
On Mon, Dec 10, 2012 at 7:52 PM, Tim Blechmann <tim@klingt.org> wrote:
* there are some test failures for msvc on 64bit platform. afaict, it is mainly a configuration issue.
I don't know enough about this, so I'll leave it up to you.
actually, i might need some help from someone who has access to msvc ...
I have committed a fix (rev. 81831) that should solve the problem. Although it seems that Windows support is rather preliminary (if I got it right, all atomic operations are implemented through CAS rather than specific atomic instructions). Let's see how the tests run.
apparently boost.atomic has been abandoned. i must admit, i'm very disappointed that the original author did hardly reacted neither on-list nor off-list.
furthermore, it is blocking the release of boost.lockfree, so i'm volunteering to maintain this library.
I thought we'd agreed that lockfree could be initially released for just compilers with native support.
yes ... however we will still be in the position that boost.atomic won't make it and i'm afraid of zillions of error reports that the library is not working on compiler XYZ ...
i'd rather see helge bahmann coming back and taking over responsibility for his code, but frankly, i lost all hopes that this is going to happen.
iac, i'd like to get permission from the release managers to merge both atomic and lockfree to the release branch.
As far as I'm concerned, lockfree is okay for merging. Could do with marking up expected failures.
regarding gcc, we would *only* have expected failures, as the required version (4.8) is neither released nor tested ... also, some of the failures are related to a timeout on the test machines ... especially the win32 test machines seem to be an order of magnitude slower than the linux ones ... which is a bit unfortunate, as lock-free data structures can only reasonably be tested with long stress tests ...
I'll get back to you about atomic. Although it needs to have the usual things dealt with (libs/libraries, libs/maintainers, libs/atomic/index.html, marking up errors).
done ... except for marking of expected failures ... i've committed some fixes, which hopefully resolve most issues ... still waiting for the tests to cycle ... tim
On 7 December 2012 16:58, Tim Blechmann <tim@klingt.org> wrote:
regarding gcc, we would *only* have expected failures, as the required version (4.8) is neither released nor tested ...
As far as I'm concerned, failures on unreleased compilers aren't an issue. It's nice to support them, but often not worth the effort.
also, some of the failures are related to a timeout on the test machines ... especially the win32 test machines seem to be an order of magnitude slower than the linux ones ... which is a bit unfortunate, as lock-free data structures can only reasonably be tested with long stress tests ...
OK, sure. Timeouts are a real problem.
On Fri, Dec 7, 2012 at 6:04 PM, Daniel James <dnljms@gmail.com> wrote:
On 7 December 2012 16:58, Tim Blechmann <tim@klingt.org> wrote:
regarding gcc, we would *only* have expected failures, as the required version (4.8) is neither released nor tested ...
As far as I'm concerned, failures on unreleased compilers aren't an issue. It's nice to support them, but often not worth the effort.
I think the point is that 4.8 is the only supported version, as < 4.8 doesn't have native atomics. -- Olaf
Hi, Boost.Atomic and Boost.Lockfree have been merged to release in revision 81976.
participants (6)
-
Andrey Semashev -
Daniel James -
DUPUIS Etienne -
Eric Niebler -
Olaf van der Spek -
Tim Blechmann