• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Dispatcher where some object is always processed by the same thread?

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So you have data to process and you want to dispatch each item based on id using modulo the number of threads you have to process any given item such that all items with the same id are processed by the same thread. Presumably this requires an addressable set of ExecutorServices?
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, I would probably create an ExecutorService[] array, and use Executors.newSingleThreadExecutor() to populate each element. Then for each thing to process, pick the appropriate array element, and submit a task to that ExecutorService.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is a SingleThreadExecutor significantly better than just a BlockingQueue with a consumer on other the end?
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not really - that's basically what newSingleThreadExecutor() gives you. It's just convenient to be able to do that in one method call. And using the ExecutorService interface can make it easier to refactor your code to use other threading implementations later, if you want to. Both benefits are relatively minor here, I think. But nowadays I like to look to the Executors class first for solutions when doing threading.
[ December 19, 2007: Message edited by: Jim Yingst ]
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Kool, thanks. Eggzellent point about the flexibility to choose other executors.
 
Bartender
Posts: 1638
IntelliJ IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am not sure why you have insisted on using the same thread?
While using an executor, thread instance is not what a client must be bothered about, instead it should be worried about the runnable/callable that is submitted.

I would presume that the task(runnable/callable) that you will submit will have the id of the item that is to be processed and enough context information to process that item.
When the task gets invoked, it can look at the id and dispatch it to the appropriate class to execute it. This will all happen in the thread of the executor.
With this you can change the executor anytime you want and all the same task ids will be processed by a dedicated class concurrently.
Additionally, you can assign a priority to each task which you will not be able to do if you have different executors for every task id.

P.S. I think this is what Stan was referring to. isn't?
Hope it answers your question.
[ December 20, 2007: Message edited by: Nitesh Kant ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic