Processing 1.0 - Processing Discourse - Multithreaded access to pixels[], ok?

davbol

Multithreaded access to pixels[], ok?
Apr 1^st, 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

JohnG Ex Member	Re: Multithreaded access to pixels[], ok? Reply #1 - Apr 1^st, 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.

Johnny Ow YaBB Newbies Offline Posts: 49	Re: Multithreaded access to pixels[], ok? Reply #2 - Apr 1^st, 2009, 7:12pm How do you create threads in Java/Processing? Do they run on different CPU cores?

JohnG

Re: Multithreaded access to pixels[], ok?
Reply #3 - Apr 2^nd, 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()
{
}

davbol

Re: Multithreaded access to pixels[], ok?
Reply #4 - Apr 2^nd, 2009, 8:05am

Johnny Ow wrote on Apr 1^st, 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.

Johnny Ow YaBB Newbies Offline Posts: 49	Re: Multithreaded access to pixels[], ok? Reply #5 - Apr 3^rd, 2009, 11:08am Wow, that is super awesome. I had no idea it was possible and so easy. Thanks for the tips!

WebDext

Re: Multithreaded access to pixels[], ok?
Reply #6 - Apr 9^th, 2009, 12:51pm

davbol wrote on Apr 2^nd, 2009, 8:05am:

Johnny Ow wrote on Apr 1^st, 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.

WebDext Junior Member Offline Posts: 79 WA	Re: Multithreaded access to pixels[], ok? Reply #7 - Apr 9^th, 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.

PhiLho

Re: Multithreaded access to pixels[], ok?
Reply #8 - Apr 9^th, 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.

WebDext Junior Member Offline Posts: 79 WA	Re: Multithreaded access to pixels[], ok? Reply #9 - Apr 9^th, 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.