Message-dispatch system in C that doesn't break strict aliasing and alignment

Question

I'm writing an embedded control system in C that consists of multiple tasks that send messages to each other (a fairly common idiom, I believe!), but I'm having a hard time designing a mechanism which:

• is neat
• is generic
• is relatively efficient
• most importantly: is platform independent (specifically, doesn't violate strict-aliasing or alignment issues)

Conceptually, I'd like to represent each message type as a separate struct definition, and I'd like a system with the following functions (simplified):

void sendMsg(queue_t *pQueue, void *pMsg, size_t size);
void *dequeueMsg(queue_t *pQueue);

where a queue_t comprises a linked list of nodes, each with a char buf[MAX_SIZE] field. The system I'm on doesn't have a malloc() implementation, so there'll need to be a global pool of free nodes, and then one of the following (perceived issues in bold):

1. sendMsg() does a memcpy of the incoming message into the buffer of a free node.
   My understanding is that this will have alignment issues unless the caller of dequeueMsg() does a further memcpy on the return value.
2. or there'll be a void *getFreeBuffer() function which returns the buf[] of the next free node, which the caller (the sender) will cast to the appropriate pointer-to-type.
   My understanding is that this will now have alignment issues on the way in, and still requires a memcpy after dequeueMsg() to avoid alignment issues on the way out.
3. or redefine the buffer in queue_t nodes as (e.g.) uint32_t buf[MAX_SIZE].
   My understanding is that this violates strict aliasing, and isn't platform-independent.

The only other option I can see is to create a union of all the message types along with char buf[MAX_SIZE], but I don't count this as "neat"!

So my question is, how does one do this properly?

Answer 1

I don't understand why 1 presents an alignment issue - as long as each buf[MAX_SIZE] element is aligned to the natural largest single primitive type that occurs in your message structs (probably 32 or 64bit), then it doesn't matter what the contents of each message type is; as it will always be aligned to that size.

Edit

Actually, it's even simpler than that. As each element in your message queue is MAX_SIZE in length, then assuming that you start each message in it's own buf (i.e. you don't pack them if a message is < MAX_SIZE) then every message in the queue will start on a boundary at least as big as itself, therefore it will always be correctly aligned.

Answer 2

The way we deal with this is to have our free list consist entirely of aligned nodes. In fact we have multiple free lists for different sizes of node, so we have lists that are aligned on 2 byte, 4 byte, and 16 byte boundaries (our platform doesn't care about alignment larger than one SIMD vector) . Any allocation gets rounded up to one of those values and put in a properly aligned node. So, sendMsg always copies its data into an aligned node. Since you're writing the free list yourself, you can easily enforce alignment.

We would also use a #pragma or declspec to force that char buf[MAX_SIZE] array to be aligned to at least a word boundary inside the queue_t node struct.

This assumes of course that the input data is aligned, but if for some reason you're passing in a message that expects to be (let's say) 3 bytes off from alignment, you can always detect that with a modulus and return an offset into the free node.

With that underlying design we have interfaces that support both option 1 and 2 above. Again, we precondition that input data is always natively aligned, so our dequeue of course returns an aligned pointer; but if you need oddly aligned data in, again, just offset into the free node and return the offset pointer.

This keeps you dealing in void *s thus avoiding your strict aliasing problems. (In general though I think you may need to relax your strict aliasing requirements when writing your own memory allocators, since by nature they blur types internally.)