Prioritized method execution in Object

Question

In my application I have an object called 'manager'.My main thread is continously calling

     manager.sendData(..);

I also want to have a thread spawned from my main thread where I make get request to a server periodically and upon any response I want to call

     manager.addQueue(..);

with highest priority.

But this is causing problems(manager.addQueue() is not being called at all) as manager.sendData(..) is continously executing(it is being called in a infinite while loop).What if any is the proposed solution?

Answer 1

Infinite while loop is the worst thing ever invented on earth when it comes to multithreading unless you are using wait() and notify() - or at least sleep() inside your loop!

You should take a look at this: A simple scenario using wait() and notify() in java

Answer 2

To quote the first few lines out of items 68 and 69 in Bloch's Effective Java, Second Edition:

Item 68: Prefer executors and tasks to threads

The first edition of this book contained code for a simple work queue [Bloch01, Item 49]. This class allowed clients to enqueue work items for asynchronous processing by a background thread. When the work queue was no longer needed, the client could invoke a method to ask the background thread to terminate itself gracefully after completing any work that was already on the queue. The implementation was little more than a toy, but even so, it required a full page of subtle, delicate code, of the sort that is prone to safety and liveness failures if you don’t get it just right. Luckily, there is no reason to write this sort of code anymore.

In release 1.5, java.util.concurrent was added to the Java platform. This package contains an Executor Framework, which is a flexible interface-based task execution facility. Creating a work queue that is better in every way than the one in the first edition of this book requires but a single line of code:...

And in the next item,

Item 69: Prefer concurrency utilities to wait and notify

The first edition of this book devoted an item to the correct use of wait and notify (Bloch01, Item 50). Its advice is still valid and is summarized at end of this item, but this advice is far less important than it once was. This is because there is far less reason to use wait and notify. As of release 1.5, the Java platform provides higher-level concurrency utilities that do the sorts of things you formerly had to hand-code atop wait and notify. Given the difficulty of using wait and notify correctly, you should use the higher-level concurrency utilities instead.

The higher-level utilities in java.util.concurrent fall into three categories: the Executor Framework, which was covered only briefly in Item 68; concurrent collections; and synchronizers. Concurrent collections and synchronizers are covered briefly in this item.

It also sounds like Java's tutorial on Concurrency may help: http://docs.oracle.com/javase/tutorial/essential/concurrency/

Answer 3

There are a few common patterns for priority handling.

Use thread priority

If you only have two threads, and you spawn the threads yourself, then you can set their priority.

Thread t = new Thread(yourRunnable);
t.setPriority(Thread.MAX_PRIORITY);
// or MIN_PRIORITY
// or something in between

Use a priority based ExecutorService

You could refactor all your calls to the manager into Runnable or Callable instances. Then, using a PriorityQueue and a Comparator of your own, it's easy to dispatch your work units to a pool of threads. See : How do I implement task prioritization using an ExecutorService in Java 5? If you really need a strong priority, this is a solution I'd recommend because the conccurent package is the current standard, "go-to", solution for concurrency, and its scalable to as many thread and priorities as you need.

Alternative options include:

Use multiple ExecutorServices

You could be to use two ExecutorService instances, one with 2 threads and another with 1, the idea would be to allow more threads to deal with your most important work, and less thread to the less important. This is more a workaround than a solution, but it's one that's easy and also (almost) guarantees your high priority task will not starve lower priority ones.

Use Locking

This is a more error prone way of solving the issue. But you could imagine locking access to your manager instance so that when an addQueue event arises, then calls to sendData get locked out untill the first event stops. But this is actually not a priority implementation, it's more of a "mutual exclusion" pattern.

Use producer / consummer pattern

You can have producer threads that create work units into one (or more) queues. Consumer threads then pop work out of this (these) queues and deal with it (call the manager). If your queue is a PriorityQueue or if you have a "high priority" and a "low priority" event queues, then your consummer has the choice of how it handles the priority based on your needs.

In any case, you should make sure you understand the ramifications correctly.

1. Priority implies that the risk of starvation is real. You should balance your needs accordingly to prevent high priority to starve low priority
2. Are you really looking for Thread priority handling, or can alternative patterns such as mutual exclusion or producer/consummer solve the issue ?