We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexProgramming Questions & HelpPrograms › Multithreaded access to pixels[], ok
Page Index Toggle Pages: 1
Multithreaded access to pixels[], ok? (Read 960 times)
Multithreaded access to pixels[], ok?
Apr 1st, 2009, 2:01pm
 
I have an app that renders individual portions (aka buckets) of an image in separate threads.  I know that in theory what I probably should be doing is maintaining a separate buffer for each of those buckets, then once each completes, have the main thread copy its buffer into the final image. (which works, but is extra housekeeping effort that might not be necessary?)

Because it appears that I can pass a reference to and write to the final image's pixels[] array directly from the threads.  That simplifies (and speeds up) the code, but I'm just wondering if there is anything inherently un-thread-safe in doing so.

Since ints are a primitive type, and so have atomic access, and since i'm only writing not reading those values, I would think it meets all the requirements for concurrency, I just don't have a definitive reference on it.  Any words of caution?  thx
Re: Multithreaded access to pixels[], ok?
Reply #1 - Apr 1st, 2009, 2:57pm
 
That sounds like it should be okay, as long as no threads do a updatePixels() on it or anything then I think you should get away with it fine, since there should be no PApplet behind-the-scenes magic going on in the background.
Re: Multithreaded access to pixels[], ok?
Reply #2 - Apr 1st, 2009, 7:12pm
 
How do you create threads in Java/Processing?  Do they run on different CPU cores?
Re: Multithreaded access to pixels[], ok?
Reply #3 - Apr 2nd, 2009, 2:04am
 
Creating threads is pretty easy, you need to create a class the implements the Runnable interface, or extends Thread.

Code:
class Dancer implements Runnable
{
int id;
Dancer(int _id)
{
id=_id;
}

void run()
{
while(true)
{
println("Dancer "+id+" dancing!");
delay((int)random(100,2000));
}
}
}

Dancer d1,d2;

void setup()
{
d1=new Dancer(1);
d2=new Dancer(2);
new Thread(d1).start();
new Thread(d2).start();
frameRate(1);//so you can see the dancing happens even without frame update
}

void draw()
{
}


Re: Multithreaded access to pixels[], ok?
Reply #4 - Apr 2nd, 2009, 8:05am
 
Johnny Ow wrote on Apr 1st, 2009, 7:12pm:
Do they run on different CPU cores


Yes... if those cores are actually available.  Use something like:
int nprocs = Runtime.getRuntime().availableProcessors();

to determine how many threads are optimal (you could create more, but they'd just task swap and actually slow things down compared to a 1-thread-per-core scheme)

Very useful when, for example, processing video and you can split the screen up into quadrants for a 4-core cpu.
Re: Multithreaded access to pixels[], ok?
Reply #5 - Apr 3rd, 2009, 11:08am
 
Wow, that is super awesome.  I had no idea it was possible and so easy.  Thanks for the tips!
Re: Multithreaded access to pixels[], ok?
Reply #6 - Apr 9th, 2009, 12:51pm
 
davbol wrote on Apr 2nd, 2009, 8:05am:
Johnny Ow wrote on Apr 1st, 2009, 7:12pm:
Do they run on different CPU cores


Yes... if those cores are actually available.  Use something like:
int nprocs = Runtime.getRuntime().availableProcessors();

to determine how many threads are optimal (you could create more, but they'd just task swap and actually slow things down compared to a 1-thread-per-core scheme)

Very useful when, for example, processing video and you can split the screen up into quadrants for a 4-core cpu.



There's a lot more behind the scenes than that however. 1 thread per core can be inefficient if the cores support hyper threading. Cores need to be kept working and hyper threading tries to solve this problem by keeping two sets of code in the core so if one thread is waiting for work from L1/L2 cache or even worse from memory - the second can hopefully do some work and keep the CPU performing calculations.

Most CPU's still have relatively low use compared to what they're capable of if they were actually used efficiently.

I'm pretty sure though it would be really hard to optimize threading in Java though since it's running in a virtual machine and kinda black boxes the entire process.

For example I don't understand how you can have two threads reading/writing from that pixel array without critical sections That must mean that every access to shared memory is wrapped in a critical section under the hood which slows the entire application down.


Re: Multithreaded access to pixels[], ok?
Reply #7 - Apr 9th, 2009, 12:55pm
 
Just found this interesting website:

http://www.java-interview.com/Java_Performance_Interview_Questions.html


So now I want to learn more about Java's non-synchronized data types. If that includes the array then having two threads access it is not safe.
Re: Multithreaded access to pixels[], ok?
Reply #8 - Apr 9th, 2009, 1:46pm
 
Yes, arrays are totally non-synchronized out of the box. You can use stuff like copy on write arrays, or synchronize the parts of code accessing the array, etc.
But it would ruin the interest of having several threads, there, it would be slower! Another way is to have a thread computing the upper part of the array while another processes the lower part: if they never use the same offsets, they will be no clash.
Re: Multithreaded access to pixels[], ok?
Reply #9 - Apr 9th, 2009, 2:44pm
 
You can also create a job system where each job is assigned start / end indicies to denote where they will work in the array. Then the job runs and exits when finished. But make sure you have a set of threads to attach the jobs to so you don't incur the start up / clean up cost for each thread.
Page Index Toggle Pages: 1