[ag-automation] application layer use cases for fieldbus stack

[Peter Soetens]

On Wednesday 11 July 2007 14:38:20 Robert Schwebel wrote:
> On Wed, Jul 11, 2007 at 01:42:25PM +0200, Peter Soetens wrote:
> > The boost C++ library (boost::shared_ptr) uses atomic increment logic,
> > and offers its own implementation for each architecture (see:
> > boost/detail/sp_counted_base_*.hpp).
>
> Hmm, they directly implement it in assembler. Bad for portability. But
> ok, one could provide a simple lock() do_something() unlock()
> implementation, for other architectures.

They do, for both Unix and Windows.

If you look closer, you'll see that Boost has an implementation per 
compiler/platform and if atomics are unknown/unavailable it uses locks. Boost 
is one of the most portable C++ libraries I have ever seen. It works even on 
eCos i386/powerpc without modification, just use the header.

>
> > Somehow, some glibc people decided that atomics/CAS did not belong in
> > userspace and are removing it from the libc headers. I don't
> > understand why, it's just another assembler instruction.
>
> Drepper says no:
> http://ecos.sourceware.org/ml/libc-alpha/2005-06/msg00121.html
>
> Do you have experience with what gcc provides here:
> http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Atomic-Builtins.html#Atomic-Bui
>ltins

I did not know it, but it looks exactly as what I was looking for. Even though 
it is GCC specific.

>
> > Orocos has also its own CAS implementations, mapping to x86, x86_64
> > and powerpc.
>
> We would at least need fast implementations for x86, x86_64, powerpc,
> arm v5 and v6 and maybe mips. And, until now, notice that there is no
> reason why the libs shouldn't compile for win32 as well, so it should
> also be possible there.
>
> All in all, I'm not too happy with non-portable implementations.

You can fallback on locks if the processor does not support any of these 
primitives.

Peter

-- 
Peter Soetens -- FMTC -- <http://www.fmtc.be>