2

I have a producer-consumer situation, where I want to decide between two mechanisms to implement it. It is an audio-recording/encoding case: The producer polls device microphone ,continuously, for the recorded audio, and when an audio sample is available, passes that sample to the Consumer, which is an encoder, to do the encoding and saving.

The two available mechanisms are:

  1. Two threads with a queue to pass messages from Producer to Consumer.
  2. Or, a Handler as the consumer, where messages are posted by the producer, when it is available.

But, I am not sure which one is more efficient:

If two threads are used with a queue, then the consumer has to run in a while loop. For example, if the task continues for 5 minutes, this loop has to run for 5 minutes. While, if Handler is used, my understanding is, that the handler (consumer) only runs when there is a message, when it's handleMessage method is invoked. (Is this assumption about how handler works true, That it does not run in continues loop?). Therefore, I conclude that in this respect, handler is more efficient.

But, on the other hand, a queue seems to be simpler mechanism, probably requiring less work, compared to Handler's message passing mechanism, which is repeated on every message (Again, is this assumption true?)

Now, based on the above two assumptions, which to me seem conflicting, I am not sure which of the two mechanism is more efficient.

Note: I did not post any code, because, I think this a generic situation.

Thanks.

Edit:

In terms of implementations, both mechanisms are relatively simple to implement. My question was rather about the run-time behavior of two mechanisms. As, I have at least 5 thread where it is critical for each of them to run continuously. Now, my question was, in such a case, which of the two options are better (Specifically for an Android application, considering how Handlers and Loopers and HandlerThread work) ?

  1. Implement N thread, each running in a while loop. Communication mechanism is simpler, a queue. But N concurrent loops.
  2. Implement producer(s) as running in a loop, but consumer(s) as Handlers. Not N concurrent loops (at least on the surface, behind the seen it might actually be the case), but a more involved communication: invoves thread message queue, Looper mechanisms, special message passing, etc.
Nazar Merza
  • 3,365
  • 1
  • 19
  • 19
  • Familiar with Otto library? Could be neat in this kind of case – Niko Feb 09 '14 at 21:15
  • Consider applying Cunningham's Law of Simplicity ("Do the simplest thing that could possibly work" (Ward Cunningham)) to help determine what to do. Decide which strategy is simplest to implement, and then do that. If it works, great! You're done! If not, you've only invested the time required to do the simplest solution - now you can go implement the more complex solution, which hopefully will solve your problem. And if THAT doesn't get it - well, that's why they make drawing boards. :-) Share and enjoy. – Bob Jarvis - Слава Україні Feb 09 '14 at 21:47

2 Answers2

0

In my opinion, the second approach would work better precisely because of your argument: you'll have to run a loop all time along, and even if this is run within a Thread, finally those are resources you waste and would be very appreciated within the expensive operation of processing that audio. This might be compensated by adjusting the Thread priorities via setPriority(...), though playing around and measuring the performance.

By the other hand, the Handler approach would natively decide when to call the consumer process and just when that happens, so you're earning resources that you'll need for the first Thread. So, even if this could bit harder to implement, I'd go by this.

nKn
  • 13,691
  • 9
  • 45
  • 62
  • Thanks for the response. But, my question was about the runtime behavior of the two mechanisms, not the implementation difficulty. – Nazar Merza Feb 10 '14 at 02:42
  • My answer is based on the runtime behavior, not the implementation difficulty. My last comment is just an aspect on implementing the solution I think will work better, but the content is behavior-oriented and what I would do to get the best performance I could. – nKn Feb 10 '14 at 07:57
  • Hi HNK, you are right. I forgot to mention that my comment was only about the last sentence in your comment, not the whole content. But, regarding the problem, I think, the only way to know is to experiment with both methods. – Nazar Merza Feb 10 '14 at 15:05
  • @NazarMerza Undoubtfully, trying both will bring you the best data from whom choose the best approach. As I haven't tested it (seems pretty interesting, though), my answer is just the *theoretical* part, maybe the other implementation comes to be more efficient. Just try both and test them. – nKn Feb 10 '14 at 15:10
  • true. My assumption was also based on logical reasoning rather than actual data. But, as you mentioned, it can be the other way around. – Nazar Merza Feb 10 '14 at 18:24
0

Handlers are executed using threads:

http://developer.android.com/reference/android/os/Handler.html

You will only be as efficient as the code that implements it. However, it it very likely your custom thread will be less efficient unless you are confident that you understand the low-level details of thread implementation vs. handler implementation.

In other words, there is no clear answer here for a generic implementation. It is case and developer specific.

Jim
  • 10,172
  • 1
  • 27
  • 36