build update #2

Removed 4.5.4 on mips32 – it seemed to fail to align correctly, which caused one of the test asserts to trigger immediately.

I think now everything should be right – I’ve now issued the full build. It’ll run overnight, and we’ll see in the morning.

build update

Lookin’ good!

Found and fixed a bug in DWCAS on 4.1.2 – 4.7.3 (related to the previous bug) and now that platform passes tests.

Have an all-compilers, ar-rel only build running now and I expect it to pass.

Then at some point I’ll need to run an all-compiler, all-variants build, which takes about six hours.

That then will finish the Linux work.

Then I’ll need to check the Windows (VM based) builds are still happy, and then the build system is all systems go!

liblfds compiled on mips64, ppc64 and sparc64

Thanks to the GCC Compile Farm, liblfds now has been built on mips64, ppc64 and sparc64!

Nicely, only ppc64 needed work – the defines in the porting layer header for the processor were wrong.

I can’t run the test programme on these platforms though – the test code runs at 100% on all CPUs for some time and would hammer the other users.

Blocking CNN

I need a plugin for firefox which will block sites, so any URL from that site is blocked.

The reason for this is not ads.

It’s CNN.

I was mentally idling, and I did something I almost never do, just out of curiosity to see what was there; I went over to

There’s a link on there to a story about a group of teenagers (youngish) who saw a man drowning in his pool and didn’t help him, and apparently taunted him, and recorded themselves doing so and him drowning, and they’re not going to be prosecuted under Florida law.

Okay, so far, so fucked up, but okay.

Then some sound starts to play – it’s taken a little while, the page has been loading.



So, this isn’t at all as twisted as what those kids did themselves, but it is still *pretty fucking twisted*.

build update

Focusing currently on latest GCC archive release builds.

Fixed a bug in the 32-bit DWCAS code for GCC >= 4.1.2 and 4.7.3.

Now what I’m left with is that test goes badly wrong on i686 with 4.5.4 and 4.6.4 and on mips with 4.5.4 (but 4.6.4 on mips is fine).

Later compilers work. I don’t have versions so far back except on x86_64, which I’ve not tried yet – so those compilers currently are only for those platforms.

The problem seems to be that DWCAS goes wrong.

Investigation continues.

Step by step!

Frickin’ A.

Just had latestgcc and release variant build on all platforms (except x64 – because I’m using it and it’s disruptive to have it going on in the background :-), test pass, and benchmark complete, and gnuplots produced.

Overnight I’ll run the full build (again, except x64, because the fan noise makes it impossible to sleep :-), all compilers, all platforms, all variants.

Status re next release

So, todo list;

1. full clean run of build system on all platforms and all supported GCCs
2. check GC working properly
3. implement GC-based freelist, queue and stack, and write their tests
4. complete singly-linked list (with add and delete)
5. try and figure out what’s happening with the performance of the unbounded/single/single queue
6. modify freelist to use offsets rather than pointers (for easier use with shared memory)
7. write a benchmark for the singly-linked list


1. get the bloody forum and mailing list working.

source control / github / versioning

I’ve opened a new github account, “liblfds2”. There will be one repo, “liblfds”. I’m going to follow a trunk-with-branches approach to source control. I couldn’t use the existing account, because it’s confusing, because of the older repos in there.

I’m using SVN myself, so I’ve moved over to the standard trunk/branches/tags layout.

libbenchmark has a private branch of the earlier versions of liblfds, with the porting abstraction layer and build files updates so they work with the current version (i.e. support the same platforms, so they can all be compiled and run together).


So, libbenchmark contains the older versions of the library (from 7.0.x onwards) so you can see how well the older versions are performing compared to the current version.

This leads to a problem where the current version can compile and run on more platforms than older versions, and this comes down to differences in the porting abstraction layer.

Deciding what to do with the abstraction layer is a bit problematic.

There are two reason for change;

1. bug fixes
2. ensuring older library versions can compile with the current benchmark app

The policy with regard to bug fix releases is of course bug fixes only.

This is not compatible with the sometimes major changes needed to work with the current benchmark app (such as adding new platforms).

The latest version may well have significant modifications (internal improvements), not just additions (new platforms).

We could imagine having two branches, one with bug fix changes only, one with an up-to-date abstraction layer for libbenchmark, but this is getting more complex for the user and also the current versioning system does not properly support this.

I begin to realise versioning systems are a straightjacket. It seems problematic to encode everything in them, but anything you can’t encode can’t happen in your source control system.

I have for a while (and originally did) have an integer version which simply increments. When you have branching, you then need something on your web-site to provide information about which version is which.

Problem is anything which isn’t directly obvious is going to lead people to mistakes.

Pick your poison.

I think what I may do is keep a private branch for libbenchmark.

Users won’t know about it, so it won’t muddy the waters.

twenty hours of debugging, problem now solved

I have just spent twenty hours (broken up by a night of sleep) debugging.

There was something amiss on aarch64 – benchmarks using DWCAS were segfaulting.

I uncovered one bug with the freelist elimination layer, which I fixed. Found another with thread startup ordering, and another with pointer/counter being the wrong way round still in 7.0.1 and 7.1.1.

Still, this didn’t fix the problem.

The particular example of the problem I focused on was this : the freelist benchmark for 7.0.1 with two threads. There’s two freelist elements, two threads, each pops and then pushes, in a tight loop. Problem is one of the threads was popping a NULL (empty freelist).

This in principle was impossible.

Well, I’ve just figured it out. After twenty hours of doing nothing but working on this, to figure it out. I’m pretty relieved and happy 🙂

So, on aarch64, I implement my own DWCAS, using LL/SC. Have to, because libatomic is totally messed up right now. I don’t use memory barriers in the DWCAS itself – for me, they’re separate, in the code itself, rather than in the DWCAS.

This means though that the DWCAS is issuing “ldxp” to load, and then “stxp” to store.

If any other thread writes to the load/store location after the ldxp, the stxp will fail – so we’re protected against other thread writing between our load and store.



So we have (say) no memory barriers. We load the original value, this prior to the DWCAS. Someone else then does a write. *We don’t see it*, because we have not issued a load barrier – and then we enter into the DWCAS. We load the wrong value – we’ve not seen their write yet – and then we compare it with the compare value we loaded prior to the DWCAS, and lo and behold, they are the same *and no one has written to the load/store location during the DWCAS*. So we store!! and that messes things up completely.

There has to be a load barrier between the load of the compare and the DWCAS.

It’s plain now – extra plain – I need data structure implementations per processor family.