I am having say 50 identical threads. They does some processing and send results to a thread waiting on a queue/channel. This is a repetitive process. So in such a case , please suggest which is the efficient method to follow.
Option 1:- Each of 50 threads open connection to queue/channel, so total of 50 connections open
Option 2:- Only one connection opened to queue/channel, each of 60 thread use the same connection id to send the results to queue/channel.
If option 2 is more suitable, will it work with open64(), lseek64() and write() also
I have no idea which is more efficient, but I would suggest Option 2 as it might be easier on the resource manager.
I don’t see what you are doing has anything to do with whether open64() and/or lseek64() work or not. They are calls to the file system.
On the other hand, why are you using the “64” calls in the first place. As I recall, they have no advantage with the QNX file system(s). Are you using a DOS file system?
I mean, if i use open() only once and each of 50 threads use the same descriptor. Each threads lseek for different offset of the same file descriptor. Will it have any issue. If a thread seeks an offset, will it affects the offset of other threads.
Yes it will. One solution would be to surround the lseek() and read() with a mutex. There might be a system call that combines a seek and a read. I only know about this because having written resource managers, I know that there is a multi-message they receive that does this. I don’t remember what the system call is. Maybe someone else reading this does?
If this is the case, it will be applicable for queue descriptors and coid also right? Or file descriptor is something different from queue descriptor and coid ?
If different threads use same coid and same queue descriptor, will is cause any data lose ?
A file descriptor (fd) is a type of void. All threads that send messages in QNX 6 do so using a void. An fd supports POSIX messages, e.g. open(), close(), read(), write() etc. I believe that queue manager descriptors are fd’s, but they certainly are coid’s.
If multiple threads use the same coid, the messages get queued at the resource manager. Normally there should be no data loss. If the fd were a file descriptor, and the two threads are mixing seek and read or write calls, then things could get out of order. That’s where a mutex or an atomic seek+I/O call would come in handy.
Actually there is a statement in the help of open64() - “In QNX Neutrino, the returned file descriptor is the same as the connection ID (or coid) used by the Neutrino-specific functions.” So i got confused.