I'm working on an Android app.

We have listeners for position data and camera capture which is timed on a background thread (not a service).

The timer thread dictates when the image is captured and also when the data is cached in a local sqlite db.

So, my question is how to properly store the location data as it comes in based on the listeners and pull that data so that the database can be updated as the camera capture is executed.

I can't put the location data into the database as it arrives because it is processed more frequently than the camera images and the camera images are what dominates the architecture at the moment. (Location data is supplement). However I need the location data to get a rough location of the where the image is captured.

My first thought was to have singleton store the location data. And have a semaphore on the getInstance method so if the database update is happening (after an image is captured) we don't have an error. The location data can wait for the database update or it can be lost for that particular event it doesn't really matter.

What are you thoughts? Am I on the right track? (And is this the right sub-site or would this be better on stackoverflow?)

1 Answer 1


I think you've got it right. Ideally you'd want the background thread handling the camera to send data straight to the database and so avoid using the singleton. This lets the database handle all the concurrency problems. But you need to trade a bit of safety for performance.

You need your picture and related data in a place where it can get referenced by multiple threads. The singleton will do fine for this (but give some thought to juggling more than one picture at once--you'll write better code). Make sure all references to the data are synchronized. Use wait and notifyAll to signal that a picture is ready. And read everything you can find on the problems of multithreading--it's a tricky and dangerous business.

Alternatively (just thought of this), you might be able to avoid multithreading--or at least the problems of multitheading--by using java.util.concurrent.ConcurrentLinkedQueue. An instance would not need to be synchronized. Your camera thread could create a data object, add (offer) it to the queue, and null its reference to it. It would need to signal your main thread to let it know it was ready. Then your main thread could take it (using poll). Once your main thread has the data object, it would no longer be visible anywhere else. The queue could work like a DB in taking responsibility for multithreading.

(Several other concurrent collections might work as well, but be sure to do the read and the remove in one method or you might find, someday, that two threads do reads before either does a remove and both think they have exclusive access to the data.)

  • +1 on using existing j.u.c data structures, often there is no need to roll your own concurrency, let Doug Lea et al do the thinking for you :-) May 30, 2012 at 16:14
  • awesome thanks. I'll post an update once we figured it out.
    – cbrulak
    May 30, 2012 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.