o2
o2 copied to clipboard
rbdannenberg
memory alignment fails on 32bit architectures
running ./arraytest compiled for the x86 architecture (aka x86_32, or i386,... 32bit intel), but also on armhf (32bit arm, as found in the RaspberryPi) aborts with an assertion:
./arraytest
arraytest: .../o2/src/o2mem.cpp:428: void o2_mem_init(char*, int64_t): Assertion `sizeof(O2queue) == 16' failed.
Aborted
on these architectures sizeof(O2queue)==8
I have no patch for this yet.
also, this is just the beginning of assertion failures on these architectures.
I didn't think about raspberry pi, although I see that future raspberry pi's are likely to be 64-bit. There's a significant issue with atomic operations on 32-bit machines and on ARM, but I'm no expert here. I found this:
... you need atomic read/modify/write operations. Those are a no-go as single instructions with ARM and any other "plain" RSIC architecture. That is why bigger ARM cores provides "instruction sequence locking" means. As the M0+ cores don't seem to provide such, I suppose you need to use the hardware spin locks provided in the 2040 chip. I din't suppose the compile will or is supposed to do this without the help of a library. But a more efficient way is avoiding atomic structures and pass data between the cores by the hardware mailboxes provided by the chip. (more discussion here: https://forums.raspberrypi.com/viewtopic.php?t=319902)
So before worrying about 32-bit, I think there needs to be the belief (and ideally, implementation) that atomic, lock-free lists are supported. (Lock-free is necessary unless the OS has a method of dealing with priority inversion that can happen between a high-priority thread, e.g. audio, waiting for a lock held by a low-priority thread, e.g. O2.)
Alternatively, you can compile without BUILD_WITH_SHAREDMEM_SUPPORT. This might still require code changes to avoid the atomic memory operations when there is no "SHAREDMEM" support, which really just means the possibility of sending O2 messages to another thread through shared memory.
Finally, you can run o2lite to connect to an O2 host, but of course that doesn't help if you want the ARM machine to be an O2 host (with full peer capability).
although I see that future raspberry pi's are likely to be 64-bit.
personally, i guess they are likely to be quantum computers.
in the meantime, it would be great if a generic solution could be found that doesn't need to make assumptions about feature sets of specific CPUs.
libatomic to the rescue.
I think 32-bit architectures work now. O2 is running on my Raspberry Pi ZeroW. On another issue, I believe some implementations of libatomic use locks to achieve atomicity, which could lead to priority inversion, so it's not suitable for O2's intended support of lock-free shared memory communication.