1

I'm writing app for Android that process real-time data. My app reads binary data from data bus (CAN), parse and display it on the screen. App reads data in background thread. A need rapidly transfer data from one thread to another. Displaying data should be most actual.

I've found the nice java queue that almost implements required behavior: LinkedBlockingQueue. I plan to set the strong limit for this queue (about 100 messages).

Consumer thread should read data from queue with the take() method. But producer thread can't wait for consumer. By this reason it can't use standard method put() (because it's blocking).

So, I plan to put messages to my queue using the following construction:

while (!messageQueue.offer(message)) {
    messageQueue.poll();
}

That is, the oldest message should be removed from queue to provide a place for the new actual data.

Is this a good practice? Or I've lost some important details?

Sergey Voronkov
  • 67
  • 7

2 Answers2

0

Can't see anything wrong with it. You know what you are doing (loosing the head record). This can't relate to any practice; it's your call to use the api like you want. I personally prefer ArrayBlockingQueue though (less temp objects).

user2023577
  • 1,752
  • 1
  • 12
  • 23
  • Thank you. I prefer to use LinkedBlockingQueue rather ArrayBlockingQueue because I have a lot of memory but a little bit of time. – Sergey Voronkov Apr 19 '18 at 09:05
  • @SergeyVoronkov: I have no clue what you mean, ArrayBlockingQueue is pretty much always better (memory and cpu), I cannot imagine 1 case why I would use a LinkedBlockingQueue. ABQ is not like arraylist, it has a put index and take index (circular buffer). – user2023577 Apr 19 '18 at 11:30
0

This should be what you're looking for: Size-limited queue that holds last N elements in Java

Top answer refers to an apache lib queue which will drop elements.

daniu
  • 14,137
  • 4
  • 32
  • 53
  • Thank you very much. It looks like exactly what I'm looking for. – Sergey Voronkov Apr 19 '18 at 09:09
  • oh please, don't import yet another 3rd party lib for replacing 1 line of code. – user2023577 Apr 19 '18 at 11:33
  • @user2023577 I do see your point, however it _is_ one of the points of classes to provide an interface with a defined behavior. Putting the responsibility to ensure an object's behavior in the caller's hands does leave an aftertaste at best. – daniu Apr 19 '18 at 11:46
  • in that case, proxy the queue: implement the wanted put/offer/add as wanted. No need for 3rd party. – user2023577 Apr 19 '18 at 11:53
  • @user2023577 Sure, better write it once more... NIH :D – daniu Apr 19 '18 at 11:55
  • @daniu: It's too simple. I think you don't understand the impact of importing yet another 3rd party on build size, risks, legal papers, tech docs, etc... – user2023577 Apr 19 '18 at 12:00
  • @user2023577 No, and neither do you, because you don't know the environment OP works in and what his requirements for all that are. I'll take his word for this being "exactly what [he]'s looking for". – daniu Apr 19 '18 at 12:07
  • S.O. is a place to give advices; he may not know what he's getting into. I provided a larger picture. – user2023577 Apr 19 '18 at 12:24
  • @user2023577 Well the question I linked also contains several answers providing new implementations as you insist is better, so my takeaway from this is that you agree the link is fine. In fact, I wanted to vote this question a duplicate but had already erroneously voted on it before, and I couldn't change that vote. – daniu Apr 19 '18 at 12:28