pouët.net

Is somebody tried multithread with Android ?
The real question is why my multithread physics is slower with mutithread (pthread) on Android while multithreading with pthread again, run faster on MacOSX or WIN32 ?
Is somebody experienced the same issue ?

note: I've tried to change priority of the threads that execute on demand a processing throught an external variable.

If only there were some profiling tools out there....

And of course, we all know that the only diff between a PC and a mobile device is the OS, so it's got to be that.

what slummy said..
bandwidth limitations / cache trashing would be an obviously place to start looking.

external variable? using some synchronisation protection.. how does it check for "on demand processing, is it using mutex/semaphores?

void * threadfn(void *data)
{
while (running)
{
if (act)
{
do(act);
usleep(0);
}
else usleep(0);
}
return 0;
}

it's thread safe, but on android it runs slower than single threaded.

Have you measured how long the sleep actually sleeps?

usleep(0) is for change threads focus.

Have you messured how long it takes.

not exaclty, I did not look at this, but why so many différences between (linux) android native code and win32 or OSX ?

Because one of them is meant for mobile devices, perhaps?

Can you measure the time it takes? On Android you can use clock_gettime(), which should be pretty accurate, at least enough to see if the program is regularly sleeping considerably longer than "zero" time units. On Win32, use QueryPerformanceCounter().

Try tracking the accurate "working" vs. "not working" start and end times for every thread, on your various platforms, and plot them on a timeline side by side. You might be surprised at what you'll see.

Without answering your question: If you want to yield control back to the OS, use sched_yield(), not usleep(0) (the OS can choose to make a short usleep into a spin loop).

Also, you should definitely not busy-poll for a shared variable to change in a thread; it's likely both to be very inefficient and plain-out wrong (memory models are very complicated beasts). You should have a shared variable under a mutex, and set a condition variable when it's updated.

with sched_yield() to switch processing threads, it works !

If you had plotted the working/not working blocks on timelines across all your threads, you might have discovered that yourself. :) Or if you had googled for a couple minutes, you might have noticed pages suggesting not to usleep(0). If you type "usleep(0)" in the search box, it will suggest searching for "usleep(0) sched_yield()".

I'd still recommend doing the graphical plotting / profiling, because you might notice many things about what's happening, and you can compare it across platforms.

indeed. thats why i asked about how the checked was done before the code was posted. i've done a lot of time critical multithreading work and if you did that kind of code on windows it would burn the cpu up and eat resources, on mobile i'd assume it would also annihilate battery life, but i'm not sure how other platforms like android would behave.

for example, on windows i'd do waitformultiobjects, using 2 mutexes a "kill event" and a "do stuff" event.. then signal those from the other threads.

i guess as well as profiling, once simple thing would be to see if the removal of the calls to usleep(0) actually make a difference at all. if they don't, that explains why performance is degraded.

Canopy: Android is stricter than regular Linux in that it can put the CPU to sleep even if badly behaved code like this is running (unless you are holding a wakelock, which requires extra permissions). So it would be mitigated somewhat; definitely not recommended, though, as it'd still burn battery while the CPU was awake. Using the OS' primitives instead of rolling your own is the only way to go here.

#include <sched.h>
sched_yield();

instead of usleep(0) or nanosleep(~0)

is the solution of the problem.

A note to kids: never ever do what Barti does in that horrible yielding busy loop, look up "job queue" and "condition variables" instead :)

I've just seen I have posted already the stuff.