Hi all,
I need to create a maximum of say 64 threads in a process. Each thread blocks on a waiting condition and should be invoked upon the request. Should i go for (1)thread pool or (2) maintain a server thread to control the activities of 64 sub threads.
Is there any difference in scheduling mechanism between the 2 designs.
Is it possible to control each thread separately in thread pool. i.e each thread in pool take different thread arguments.
Regards,
hello
The advantage of using ThreadPool is to avoid the overhead of creating/destroying and re-creating threads. For example, a webserver may use a thread to process each connection … there are many connections per session with a user. In this case you want to reuse these threads and not “destroy/re-create” them. And yes, a threadpool thread gets a parameter so he knows what to work on.
I would create the 64 thread ahead of time, the reason is that you are sure there won`t be any resource issues when trying to create the thread later on.
I would like to create all the 64 threads on startup of the application. Each thread needs to wait for a condition. Also i need to invoke each thread independently( for example, each thread waits for different semaphore, during run time in need to invoke each thread by invoking each semaphore separately) . Is this possible with thread pool.
Also in thread_pool_create(), we pass the thread_pool_attr_t structure as one argument. So each thread shall be using the same arguments. So how to differentiate each thread with different thread arguments.
One more design concern, Is it good to implement 64 threads in a single process or do we need to split up the threads to different processes ?
Each threads uses IPCs for communicating with each other
So much to say here, so little time.
First of all, you can pass a (void *arg) parameter when you start a thread. The thread could use a local automatic variable (allocated on the stack) to keep track of itself. There’s also a way to allocate a thread specific piece of memory.
But something smells bad here. Sure if I had say a board that had 64 inputs and a trigger for each, and the whole thing was symmetric,… then I’d be thinking about a process with 64 threads.
But if you are used to programming on a Windows system, and you are used to creating a gigantic process with a thread for everything, yes you can do this in QNX, but you are missing a lot. Before QNX 6, there were no threads at all, just lots of processes that communicated mostly through message passing, but occasionally using shared memory. Separating things logically into separate processes has lots of advantages and few disadvantages. That is unless you don’t care about robustness.
There, enough heavy handed opinion.
BTW, thread_pools are a nice add on, but they don’t give you anything you can’t create yourself with the more primitive pthread*() calls. So if a thread_pool matches the functionality you want, I’d use it. I agree with the other poster that if you just need 64 threads and that’s all, just create them. Thread pools make the most sense if the number of threads may grow and shrink and you want to conserver resources.
I am not clear on the reply to the below question
“Is it good to implement 64 threads in a single process or do we need to split up the threads to different processes ?
Each threads uses IPCs for communicating with each other”. Does it cause any scheduling related issue that i should consider
Does QNX do process based or thread based scheduling?
Also i am concluding the replies to thread pool related queries. Please confirm
It depends on what the 64 threads are doing. You don’t need to split the threads up. If they are all doing the same thing then it probably makes sense to keep them in the same process. Another issue is whether they interact with each other. If not, you could create 64 processes.
Is this a statement or a question. If you are using IPC to communicate with each other, then it sounds like 64 processes might be better.
Not that I can think of.
Thread based
Yes
I don’t know how to answer this. Creating and controlling threads with pthread_*() routines is what the thread pool code does.
What I said in my reply is that if all you are going to do is create 64 threads and have them run, you are better off using pthread_create() 64 times. The thread pool will create and destroy threads as needed. If you always need 64, then why use it?
I will explain the situation clearly. There are almost 74 threads in a process and each thread communicates with each other using IPCs. Of this i need 64 threads in a single process itself. Issue is with the other threads. Should i re-consider splitting the threads to different process. Threads are created at run time and destroyed at run time. So if i go for process, the each process will be created and destroyed during run time.
From my knowledge, advantage of using thread is
Is there any disadvantage in using multiple threads in a process?
Some disadvantage to using multiple threads in a process are, an error in one thread brings down the entire process and bugs related to race conditions or memory violations can be very hard to find.
“copies of process information” i mean (e.g., file descriptors).
Ok apart form this, is there any scheduling related issue
If you are asking whether there is a scheduling difference between many threads in a process and many processes with one thread, no.
Ok , thank you
In practice, threads are more efficient - not due to scheduling (as was pointed out), but due to the number context switches. When execution changes between two processes, there is always a context change - but when execution changes between threads, the new thread stack and data are in the same context.