Design problem: coalescing objects sent to a Handler

I'm looking for advice or critique of a design concept for coalescing Runnable objects posted to a Handler. The case is that I have a background thread that generates small chunks of work that must be done on the event thread. Each chunk is posted to a Handler as a Runnable in the usual way. It turns out that if one of these Runnables has not started executing, it would be easy to modify it to do additional work when it does run instead of constructing and posting another Runnable. This coalescing of work chunks would be both cheaper than constructing another Runnable and would also cut down on the problem of the background thread flooding the event queue.

There are a couple of problems, though. First, I need to have access to the last Runnable delivered to the event queue. As far as I know, neither Handler nor Looper offer any such function, so I was planning to just keep a reference to the last posted Runnable in my background thr开发者_StackOverflow中文版ead code. I'm just assuming that maintaining a reference like this isn't going to cause problems anywhere in the system.

The more serious issue is that I'd have to have some way of knowing if a Runnable has been taken off the queue and started. I plan to handle that by adding a flag to my Runnable class and setting at the start of the run() method. There would still be some synchronizing necessary to avoid race conditions between testing the flag and updating the Runnable (background thread) and setting the flag once the Runnable starts executing (event thread).

Has anyone done anything like this, and if so, how did you do it? Am I overlooking something that I need to deal with?

That seems like a way to code some nasty bugs. I have a program, that receives feed veeeeery often and posts it on multiple components, and it actually doesn't do much harm and doesn't have any visible side effects.

If you really want to go with it (I might not fully understand your situation), wouldn't it be easier, to have some "work chunks" pool, where all the needed work will be stored and some kind of work starter that will launch a new Runnable once in a while. It goes like this:

With the first event, the "work starter" posts a runnable to a handler. This runnable asks the pool to give him all the work currently available and processes it, at the end it tells the "work starter" that it has finished, starter runs another runnable, that asks the pool for a new work, etc... The runnable you post can be a subclass of your own worker runnable, to make those queries to the pool and report about finished work easier. No need to store flags, or change runnables. And no need to deal with concurrency problems (if you have only 1 handler that is)