4

I am developing a VoIP based application which is multithreaded. For every socket there is a c++11 std::thread (including SSL read & write). The core module for data communication is in C++ which is called through JNI interface.

My observation is that, once initializing the application after few seconds, some threads which were running earlier normally are not getting running time. If a certain thread is running then it keeps running for a while ranging from 3-4 seconds to 30-40 seconds.

After referring change native thread priority on Android, I also tried changing "nice" value to -10 for all the threads, but no luck. Important to note that exactly same C++ code is working perfectly fine for iOS.

Is there an issue with Android Native thread scheduling, or am I missing something?

Community
  • 1
  • 1
iammilind
  • 68,093
  • 33
  • 169
  • 336
  • We use quite a bit of threads in our Android testing runs at work (ARM), and I'm not aware of any particular issues there. I would suspect that your application is doing something "not within the rules" (or having incorrect/undefined expectations). – Mats Petersson Dec 12 '14 at 09:22
  • @MatsPetersson, could be possible. The interfaces with the C++ are different in iOS and Android. We also have sockets (and PJSIP), which may behave different based on platform or written code. Does that mean , the issue mentioned in question is not an issue? – iammilind Dec 12 '14 at 09:59
  • 1
    Can you get a stack trace? When the threads aren't running, where are they sitting? I'm wondering if the difference is in I/O handling rather than something like thread scheduling. On recent versions of Android, with a rooted device, you can use `debuggerd -b ` to dump the threads. – fadden Dec 12 '14 at 15:38
  • There is clearly an issue SOMEWHERE, but there are lots of possible scenarios where it's either a layer on top of the Android OS, or some part of your own code, that isn't working correctly. Which is to say "you need to figure out what is going on, but it's unlikely the threads in Android itself is broken, and quite unlikely that Android with C++ std::thread is broken". That's a bit like saying "my code doesn't work `int x = 42; printf("%f\n", x);`, is printf b0rked?" - if you are using a fundamental service (and std::thread and the android OS's threads are basic), it's unlikely the problem. – Mats Petersson Dec 12 '14 at 22:21
  • @MatsPetersson, I have fixed the threading related issue by fixing 1 race condition. However the voice issue is still not completely fixed. We are using PJSIP as internal SIP stack. Sometimes the voice quality is good and sometimes it's bad. In the logs when we see the packets flowing, we don't see any difference between a "good" and "bad" call. – iammilind Dec 29 '14 at 14:13
  • Sorry, been away. Not an expert on SIP, suggest you start a new question on specific issues. – Mats Petersson Jan 04 '15 at 22:12

1 Answers1

1
while (...) {
 int selectResult = select( fd, ...);
 if ( selectResult > 0 ) DoSomeWork( fd );
 else nanosleep(...); /* this is the new line which solved my stalling threads */
}

I had a similar problem, and found that for my case the solution was to verify that those threads that have an eternal loop (constantly performing select until there is something on a socket to spawn a handler thread), always call nanosleep at least once in their loop.

Like you, I experienced this issue on Android, and no issue on iOS.

I can only hypothesise that the JVM on Android sometimes would give full priority to one thread which is only polling a socket without pausing, such that other threads which had actual work to be done would stall. But I wouldn't know how to verify that hypothesis.

It's also weird that my solution works, given that select already uses a user-chosen timeout, such that I would think it internally sleeps anyway. Apparently not on Android.

wessel
  • 534
  • 5
  • 15