posix queue vs custom 0 copy queue for intra-process thread communication

Question

This is a design issue. Often Posix queues are preferred over anything custom because they are thoroughly tested, and offer advance features such as priority queuing that can be key to development. However, if we analyze it from an INTRA process communication point of view, how good they are if they are to be used only between multiple threads of same process sharing data. Does POSIX Queue optimize its messaging by removing unnecessary copy_to_user and copy_from_user once it recognize that the sender and receiver share the same address-space?

Answer 1

Your queues have two roles: exchanging data between threads and synchronizing them.

Apparently, your alternatives are posix queues, or your own queue (with a pthread mutex and condition variable for locking & synchronization).

For intra process communication, the volume of the data exchanged is not really a concern, since you can always just transmit the pointer of the data (and have the convention that the emitting thread is malloc -ing it while the receiving thread will free it after consumption).

I would guess (but you have to measure) that Posix queues might be slightly slower, because they probably involve a syscall for every operation. In contrast, pthread operations involve a syscall ( futex(2) ) only for contention (and in the common case of non-blocking operation, a mutex don't do syscall).

I am not sure the kernel could optimize the message passing to avoid the copy_to_user because it may not know when is a queue only for one process (it cannot predict that no other process would mq_open the same queue later).

And you could also use a pipe internal to the process (with poll on the recieving side).

But you really have to benchmark. I am not sure it is such a big issue.