We are working on an application where a set of objects can be affected by receiving messages from 3 different sources. Each message (from any of the sources) has a single objec
[Is] dedicating worker threads to a particular set of objects is a better/faster approach?
I assume the overall goals is to trying to maximize the concurrent processing of these inbound messages. You have receivers from the 3 sources, that need to put the messages in a pool that will be optimally handled. Because messages from any of the 3 sources may deal with the same target object which cannot be processed simultaneously, you want someway to divide up your messages so they can be processed concurrently but only if they are guaranteed to not refer to the same target object.
I would implement the hashCode()
method on your target object (maybe just name.hashCode()
) and then use the value to put the objects into an array of BlockingQueue
s, each with a single thread consuming them. Using an array of Executors.newSingleThreadExecutor()
would be fine. Mod the hash value mode by the number of queues and put it in that queue. You will need to pre-define the number of processors to maximum. Depends on how CPU intensive the processing is.
So something like the following code should work:
private static final int NUM_PROCESSING_QUEUES = 6;
...
ExecutorService[] pools = new ExecutorService[NUM_PROCESSING_QUEUES];
for (int i = 0; i < pools.length; i++) {
pools[i] = Executors.newSingleThreadExecutor();
}
...
// receiver loop:
while (true) {
Message message = receiveMessage();
int hash = Math.abs(message.hashCode());
// put each message in the appropriate pool based on its hash
// this assumes message is runnable
pools[hash % pools.length].submit(message);
}
One of the benefits of this mechanism is that you may be able to limit the synchronization about the target objects. You know that the same target object will only be updated by a single thread.
Do people agree with the assumption that dedicating worker threads to a particular set of objects is a better/faster approach?
Yes. That seems the right way to get optimal concurrency.
Assuming this is a better approach, do the existing Java ThreadPool classes have a way to support this? Or does it require us coding our own ThreadPool implementation?
I don't know of any thread-pool which accomplishes this. I would not write your own implementation however. Just use them like the code outlines above.