I'm programming with the embedded device running Linux, where memory is less, I just have 64MB flash only. I planned to use queues for the thread communication.
In which I came across with using POSIX queue or just use the simple queue.
Actually, my need is I don't want the queue to be priority driven. I want to know the pros and cons of POSIX queue then I'll have a good picture
I'm wondering what's the best-optimised way using POSIX queue or just simple queue to my situation?
First thread does HTTP POST and Second thread does HTTP GET. These two threads need to communicate when the data is written or get.
I read that POSIX queue uses Linux kernel, in that case, it has more overhead than using own data structure queue?
In other words, lightweight IPC, something like unidirectional pipes for thread communication instead of POSIX queue but don't know the real advantage of POSIX queue.
EDIT: I just have 512MB RAM in my embedded device.
Best Answer
A POSIX queue (see mq_overview(7)) is for inter-process communication (so is quite expensive, but it could be used for inter-thread communication). You could use a queue data structure protected by e.g. a POSIX mutex. Hopefully (thanks to futex(7) probably used by pthreads(7)) you won't need a context switch to the kernel in the common cases where no locking is needed.
AFAIK the flash device is more a disk -i.e. a block device- than a memory. POSIX queues or pipes will consume RAM (actually virtual address space and kernel memory space), not flash.
If you already have some event loop (e.g. around poll(2) or the old select(2) ...) you could set up a pipe(7) to self at initialization time (and have one thread writing the pipe, and another reading it).
Did you consider using some HTTP client library like libcurl (perhaps using its multi mode)? It could be helpful (and you could avoid multi-threading if you think in continuation-passing style).
For synchronization purposes (in a multi-threading approach) the "simple queue" needs e.g. some mutex (to lock & serialize access hence avoiding both threads modifying it simultaneously; the kernel is still involved thru futexes on contention). I don't know what is faster (I am not sure it is important but I would prefer mutexes & multi-threading), and you need to benchmark if you really care.
BTW, multi-threading (and also multi-processing) is consuming memory (since each thread probably wants at least one megabyte for its call stack).