Boost.Atomic request for review/inclusion
Hello, First of all I would like to thank for the comments that I have received so far, I have incorporated almost all of them I think. Boost.Atomic is now in a form that I consider calling it a release. It has support for "true" atomic variables on: - gcc/x86, 32-bit (tested on Linux, FreeBSD) - gcc/x86, 64-bit (tested on Linux) - gcc/powerpc32 (tested on Linux, Mac OS X) - gcc/powerpc64 (untested) - generic Win32 (tested with Visual Studio Express on Win XP) For all others it falls back gracefully to locked operation. There is proper quickbook documentation, including a hopefully illustrative example section. If you have an unsupported platform, contact me and I will attempt to provide support for it (usually it is just a matter of testing). Otherwise I would like to request considering the library for inclusion and appreciate any further comments. Everything available as usual at: http://www.chaoticmind.net/~hcb/projects/boost.atomic Best regards Helge
Helge Bahmann wrote:
First of all I would like to thank for the comments that I have received so far, I have incorporated almost all of them I think. Boost.Atomic is now in a form that I consider calling it a release. It has support for "true" atomic variables on:
- gcc/x86, 32-bit (tested on Linux, FreeBSD) - gcc/x86, 64-bit (tested on Linux) - gcc/powerpc32 (tested on Linux, Mac OS X) - gcc/powerpc64 (untested) - generic Win32 (tested with Visual Studio Express on Win XP)
For all others it falls back gracefully to locked operation. There is proper quickbook documentation, including a hopefully illustrative example section. If you have an unsupported platform, contact me and I will attempt to provide support for it (usually it is just a matter of testing).
Hi Helge, I will have a look at merging my ARM implementation with this ASAP. git-foo is probably the hardest part. One thing I mentioned before, which doesn't seem to have changed in this version, is your use of reinterpret_cast rather than const_cast in cases like this: *reinterpret_cast<volatile T *>(&i)=v; I suggested that this should be const_cast<volatile T&>(i)=v. Any thoughts? (Anyone else?) Cheers, Phil.
On Tue, 15 Dec 2009, Phil Endecott wrote:
Helge Bahmann wrote:
First of all I would like to thank for the comments that I have received so far, I have incorporated almost all of them I think. Boost.Atomic is now in a form that I consider calling it a release. It has support for "true" atomic variables on:
- gcc/x86, 32-bit (tested on Linux, FreeBSD) - gcc/x86, 64-bit (tested on Linux) - gcc/powerpc32 (tested on Linux, Mac OS X) - gcc/powerpc64 (untested) - generic Win32 (tested with Visual Studio Express on Win XP)
forgot venerable alpha here (not that anyone cares, except for me...)
Hi Helge,
I will have a look at merging my ARM implementation with this ASAP. git-foo is probably the hardest part.
Thanks, this is much appreciated; if you don't want to, you don't need to fuzz with git (plain patches or files are as welcome)
One thing I mentioned before, which doesn't seem to have changed in this version, is your use of reinterpret_cast rather than const_cast in cases like this:
*reinterpret_cast<volatile T *>(&i)=v;
I suggested that this should be const_cast<volatile T&>(i)=v. Any thoughts?
you are right, this comment of yours unfortunately slipped my attention. Will be fixed. Best regards, Helge
Helge Bahmann wrote:
On Tue, 15 Dec 2009, Phil Endecott wrote:
I will have a look at merging my ARM implementation with this ASAP. git-foo is probably the hardest part.
Hi Helge, I have posted a patch here: http://chezphil.org/tmp/boost_atomic_20091217.patch This has a certain amount of noise in it, sorry. This is the result of git diff e0fa477e1e812ffc0d94160bbc7bb28365c6fe1e where that commit code is from "git log". I presume there is a better way to do that. Feel free to educate me. A few points to note: - This needs a fix to boost/detail/endian.hpp per my message yesterday. - The oldish Boost tree that I have on that machine has boost/detail/spinlock_pool.hpp not boost/smart_ptr/detail/spinlock_pool.hpp (used in your fallback.hpp). Presumably it has been moved at some point; if it is now to be used here, perhaps it should move back to the higher-level directory? - I have suppressed a few unused args warnings in fallback.hpp. - My Linux code is completely untested as my cross-compiler is broken. Can anyone else help with this? - My asm version for ARM v6+ has been tested with Apple's iPhone cross-compiler and your tests/simple.cpp passes. - I don't know how to make this work in Thumb mode (this is a mode in which the processor uses a subset of the instruction set with a more compact encoding; it doesn't include all of the instructions and you can only change mode at function entry/exit.) ARM v7 also seems to be more complicated that I thought in this respect. Are there any Thumb experts out there? Now what I'd really like is for someone to port shared_ptr to use this... Regards, Phil.
Phil Endecott wrote:
I have posted a patch here:
There's a new version of my ARM patch here: http://chezphil.org/tmp/boost_atomic_20091220.patch This adds support for Thumb mode; it wraps each asm block with code that changes to/from normal ARM mode. (Thumb mode doesn't include the load-locked/store-conditional instructions.) This has been superficially tested, but it would all benefit from some more eyes. Phil.
Phil Endecott wrote:
There's a new version of my ARM patch here:
Another update here: http://chezphil.org/tmp/boost_atomic_20100103.patch This adds support for ARM architecture v7. It seems to compile but hasn't been properly tested. I have noticed a few posts here from other people writing iPhone code; if you would like to try out a shared_ptr that uses this for its atomic reference count, please let me know. I think it would be great to get Helge's code adopted as Boost.Atomic ASAP and to port things like shared_ptr to use it. As usual the limiting thing is presumably a review manager... One thing that seems to be missing is a test that actually tries to check for atomicity, i.e. by running multiple threads. Helge, do you have something? Does anyone else have something that can be adapted for this? Happy New Year, Phil.
Hi Phil, On Sun, 3 Jan 2010, Phil Endecott wrote:
Phil Endecott wrote:
There's a new version of my ARM patch here:
Another update here:
thanks, will pull within this week [...]
One thing that seems to be missing is a test that actually tries to check for atomicity, i.e. by running multiple threads. Helge, do you have something?
As far as atomicity goes, yes I have a few tests (quick'n'dirty, not in the repo yet), but testing for memory ordering is still completely lacking. Helge
Hi, I was looking for some kind of atomic counter which is able to deal with 64 bit values on 32/64 bit machines. I was just wondering if this could be done with this library on Windows (yes, I know). As far as I can see it uses the InterlockedIncrement() API methods internally. But for 64 bit values you have to use InterlockedIncrement64(). Has anyone of you tried this? Ronny
Am Friday 29 January 2010 15:08:22 schrieb Ronny Spiegel:
Hi,
I was looking for some kind of atomic counter which is able to deal with 64 bit values on 32/64 bit machines.
I was just wondering if this could be done with this library on Windows (yes, I know). As far as I can see it uses the InterlockedIncrement() API methods internally. But for 64 bit values you have to use InterlockedIncrement64().
I don't have access to any win64 machine. Are you willing to do you a few compile/test/report cycles if I implement it, so we can get this added? Best regards Helge
Hi Helge,
I don't have access to any win64 machine. Are you willing to do you a few compile/test/report cycles if I implement it, so we can get this added?
should be no problem. I have a win64 machine running visual studio 2005 here. If you send me a patch, I'll give it a try. I didn't have enough time to have a closer look at the source to know if I could do this by myself - but I think so :) Regards, Ronny
"Ronny Spiegel" <ronny.spiegel@googlemail.com> wrote in message news:d81ab4001001290608i31bed028u1d843faaa433ce33@mail.gmail.com...
Hi,
I was looking for some kind of atomic counter which is able to deal with 64 bit values on 32/64 bit machines.
I was just wondering if this could be done with this library on Windows (yes, I know). As far as I can see it uses the InterlockedIncrement() API methods internally. But for 64 bit values you have to use InterlockedIncrement64().
Has anyone of you tried this?
FWIW, you can do a loop-free 63-bit counter on a 32-bit machine by using the following clever algorithm from Joe Seigh: http://groups.google.com/group/comp.lang.asm.x86/browse_frm/thread/15271b4da...
Hi Helge, I've found some probs on XP (msvc-9.0) and FreeBSD (gcc-4.2.1): XP: boost/atomic.hpp(167): warning C4800: 'intptr_t': Variable wird auf booleschen Wert (TRUE oder False) gesetzt -> you could disable the warning with: # if defined(BOOST_MSVC) # pragma warning(push) # pragma warning(disable:4800) # endif # if defined(BOOST_MSVC) # pragma warning(pop) # endif boost/atomic/detail/builder.hpp(141): warning C4146: Einem vorzeichenlosen Typ wurde ein unärer Minus-Operator zugewiesen. Das Ergebnis ist weiterhin vorzeichen los. boost/atomic/detail/builder.hpp(360): warning C4244: ' return' Konvertierung von unsigned int in unsigned char FreeBSD: boost/atomic/detail/gcc-x86.hpp:63: multiple definition of 'void boost::detail::atomic::platform_atomic_thread_fence<boost::memory_order>(boost::memory_order) regards, Oliver
On 12/15/2009 09:37 PM, Helge Bahmann wrote:
Hello,
First of all I would like to thank for the comments that I have received so far, I have incorporated almost all of them I think. Boost.Atomic is now in a form that I consider calling it a release. It has support for "true" atomic variables on:
- gcc/x86, 32-bit (tested on Linux, FreeBSD) - gcc/x86, 64-bit (tested on Linux) - gcc/powerpc32 (tested on Linux, Mac OS X) - gcc/powerpc64 (untested) - generic Win32 (tested with Visual Studio Express on Win XP)
For all others it falls back gracefully to locked operation. There is proper quickbook documentation, including a hopefully illustrative example section. If you have an unsupported platform, contact me and I will attempt to provide support for it (usually it is just a matter of testing).
Otherwise I would like to request considering the library for inclusion and appreciate any further comments. Everything available as usual at:
i have adapted my boost.lockfree proposal to make use of your boost.atomic libray. so the review of boost.atomic should happen before or a the same time as the review of boost.lockfree. thanks a lot for your work! cheers, tim -- tim@klingt.org http://tim.klingt.org Happiness is a byproduct of function, purpose, and conflict; those who seek happiness for itself seek victory without war. William S. Burroughs
participants (6)
-
Chris M. Thomasson -
Helge Bahmann -
Oliver Kowalke -
Phil Endecott -
Ronny Spiegel -
Tim Blechmann