This content has been marked as final. Show 3 replies
I'm not completely clear on your questions. You can create a thread pool in a RT system the same basic way as in non-RT but you need to deal with priorities correctly. One way to do this would be to have the pool threads run at maximum priority normally and then drop to the actual priority of a submitted work task. Another model is to split the pool into groups based on priority, so effectively there is a work queue per priority-level and a group of threads to service each pool. This second model is used in the Real-time CORBA "lanes" approach. Designing an effective thread pool is a non-trivial task (take a look at the java.util.concurrent Thread PoolExecutor) and dealing with RT priorities and RT latency issues makes it even more complex.
Alternatively rather than use an explicit thread pool consider whether you can convert the design to one using AsyncEvents and AsyncEventHandlers.
Question 2 I don't really understand. Pool threads typically block on a queue waiting for work tasks to appear. But you can also have a non-terminating task that effectively picks up its own work from elsewhere - eg a task that reads from a socket to get the next "job" to process. Any interaction between threads is going to cost CPU time, whether a pool is involved or not, but yes there will be overhead associated with a pool, just as there is starting and terminating a thread, or performing any kind of thread coordination/synchronization.
first of all thanks for your reply.
now let me explain my second question.
as u already know we concerned allot regard performance behavior.
and one of our consultant suggest not let the thread finish its work and sent him back but just let him (the thread not the consultant :)) "sleep" or wait to continue his mission.in this way we not send him back to the poll and save time for continue the task.
in my opinion it seems to me i waste one of my resources (thread) that wait and not do nothing.
in your opinion is it a significant time between each remove back etc...?
The "sleep or wait" that you would do is effectively what would happen if the thread returned to the pool. Typically a pool thread would simply call take() on a blocking queue and so wait for more work to arrive - or proceed immediately if work was already there. Now depending on what pool implementation you are using you might be able to implement a lighter-weight synchronization mechanism that is specific to your exact requirements - but you're effectively re-inventing your own work-queue approach.
The reasons for using a thread pool are to typically throttle the number of threads that you would otherwise create in response to the expected workload, and to amortize the thread creation and termination costs across multiple tasks. To that you have to add back in the cost of coordinating the thread in the pool itself.
When a thread completes a piece of work it has to do something to cause it to give up the CPU - whether that's a sleep, a wait, or by dropping its priority such that it will only execute if there is nothing more important to be done. Whatever that thread does, you then have to do something to make it start on the next piece of work.