OSDev.org

Turdus, have you looked at the QNX API to which OSWhatever is referring ?

In the QNX synch message API a thread can send a message to itself. In fact a thread can call asyncmsg_put() multiple times and then that same thread can retrieve all those messages with a single call to asyncmsg_get().

How is that possible ? If you answer that question you will answer OSWhatever's original question.

gerryg400 wrote:In the QNX synch message API a thread can send a message to itself. In fact a thread can call asyncmsg_put() multiple times and then that same thread can retrieve all those messages with a single call to asyncmsg_get().

How is that possible ?

I simply don't understand your question. Why wouldn't it possible? On asyncmsg_put() you save the message in a buffer (receiver side), and increase pendingmessagescounter variable (on receiver side). Because it's async, sender is not blocked, so continues execution. After a while it calls asyncmsg_get() (because sender=receiver in this example) which has a condition: is pendingmessagecounter>0? Yes, so it returns a pointer to the buffer. It does not matter, how the buffer allocated (can be userspace alloc). What's the problem?

turdus wrote:I simply don't understand your question. Why wouldn't it possible? On asyncmsg_put() you save the message in a buffer (receiver side), and increase pendingmessagescounter variable (on receiver side). Because it's async, sender is not blocked, so continues execution. After a while it calls asyncmsg_get() (because sender=receiver in this example) which has a condition: is pendingmessagecounter>0? Yes, so it returns a pointer to the buffer. It does not matter, how the buffer allocated (can be userspace alloc). What's the problem?

I didn't say it's impossible. I just wonder how is it possible.

The question is, when is the memory on the receiver side allocated ? It must be allocated when the sender calls asyncmsg_put() or else there would be nowhere to copy the message. But how ?

When you send a message you block, the kernel stores a description of your buffers and copies to the target process when requested. malloc() doesn't matter, the kernel will happily copy to free()d memory if you want to do that

Albert wrote:When you send a message you block, the kernel stores a description of your buffers and copies to the target process when requested. malloc() doesn't matter, the kernel will happily copy to free()d memory if you want to do that

If you send an asynch message you don't block.

Think about things carefully. What code is the thread going to run next time it is scheduled after performing IPC? Whatever code followed the system call, of course.

So, quite clearly the memory can be freed there. The information required is implicit in the context of the call.

However, nowhere does that API say that the message is automatically freed on put.

Its also quite clear that all the receive buffers are pre-allocated.

gerryg400 wrote:

Albert wrote:When you send a message you block, the kernel stores a description of your buffers and copies to the target process when requested. malloc() doesn't matter, the kernel will happily copy to free()d memory if you want to do that

If you send an asynch message you don't block.

No, but you don't send much in the way of data either, you get a 32 bit integer and a 7 bit message ID

Albert wrote:No, but you don't send much in the way of data either, you get a 32 bit integer and a 7 bit message ID

We were talking about asyncmsg_put() not MsgSendPulse(). They are quite different.

I'm only guessing here but as I see it, the asynchronous messaging in QNX is completely a construction in user space. Still QNX is designed around synchronous messaging as the IPC of choice. I would guess that they create a high priority receiver thread that waits for a synchronous message, allocated memory, then put it on queue and if necessary wake up the real receiver thread. This will have a limit on how large asynchronous messages can be in each transfer, however there is a possibility to chain several messages.

This is a pretty simple solution but have the overhead of a context switch for every message. The question is if this is a better solution than my kernel supported asynchronous messages.