ease portability: libatomic_ops

libatomic patch from the git repo

Looks good. I've attached the patch from the git repository to this ticket. I guess all we need now is an update to scons to include libatomic_ops (detecting the installed version, inclusion in linker flags, if necessary...)

sobukus: Do you have the required scons changes as well?

The idea is good, but I'm not sure what exactly is libatomic_ops bringing to the table. First, the releases are old and the project unmaintained and, as noted on the main page, it is a part of the bdwgc garbage collector tree now. You'd have to extract maintained code from there. Second, the implementation for many architectures is very incomplete (look at sparc, for example) and untested, and the code is literally sprinkled with FIXMEs. Quantity (of ported archs) doesn't replace quality here. IMHO, atomic operations are something you either have right or don't have at all, and, in that case, revert to using something slower like pthread mutexes.

Well, so perhaps libatomic_ops is not the final answer to this. But it is clear that it is total nonsense to recreate these macros/functions all over again for jack, ffado and whatnot. Since jack seems to have working code for alpha inside (sort of, with my builds I was able to record 8 channels with my FA-101, but I had occasional crackling in the sound -- not underruns, as it sounds?), why not at least merge these efforts and make a common header/library with this tricky stuff?

holin: did you look at the current code from http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.1alpha3-080224.tar.gz ? I guess it's not much changed from the "old" libatomic_ops... actually, it looks older, when I look at the diff of atomic_ops.h .

So, I'm back at my basic statement: The idea of libatomic_ops is a necessary one. I don't particulary mind in what form it is realized, but I guess the optimum would be to merge the efforts of jack, ffado and Hans Boehm, possibly convincing him to make libatomic_ops a separate release again, or just forking off useful bits. I don't see much vlaue in competing implementations here. This is basic enough that "the one" correct implementation is enough, isn't it?

Especially since you have these operations right or not at all, we should make sure that if someone has the right one, everyone should use it. For now I have my patch in local use... I won't insist on using it in the release when we find an even better solution;-)

adi: I went the lazy route without scons stuff; there's no linking needed... just included the header, build system unaware.

sobukus: I was looking at their cvs repo.

Yes, indeed, a correct implementation is all that is needed. I'd say, do what jack has done and copy the relevant bits from the linux kernel sources, but NOT for all possible archs, just the ones that are actually used and tested by someone.

I don't think we need to have anything to do with Boehm's garbage collector project, unless somebody wants to contribute code there. FWIW there are many other projects that have local atomic ops implementations, sometimes done from scratch due licencing (or ignorance.) As nice as it is to try to avoid duplicating effort, I think it should be enough for us to have a good implementation in ffado and make sure it eventually propagates to jack/jackmp/ardour (if it uses atomic ops).

In the end, I don't really care what the solution is, as long as I don't have to start filing patches to <some obscure project> upstream and/or distros before I can get ffado going on my 64-bit SMP ppc box or ultrasparc or whatever other-than-x86 arch.

Is this still an issue with the latest changes for sparc and ia64?

We completely forget about this and go for the approach in #280.