Processing 1.0 - Processing Discourse - another multithreading question

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.

Index › Programming Questions & Help › Syntax Questions › another multithreading question

‹ Previous Topic | Next Topic ›

Pages: 1

another multithreading question (Read 1028 times)

memo

another multithreading question
May 20^th, 2008, 5:22pm

Hi all, I have an installation coming up in 6 weeks which I have a few technical questions about. I am reading camera data, analysing the data, and outputting a bunch of visuals in response. The visuals consist of fluid dynamics and many other elements.

I will be running on an 8-core Mac Pro so would like to spread the tasks into at least 3 threads (camera analysis, fluid solver, main app) if not more. I've searched on the forums and found these two threads which are very useful:
http://processing.org/discourse/yabb_beta/YaBB.cgi?board=Syntax;action=display;num=1196767252
http://processing.org/discourse/yabb_beta/YaBB.cgi?board=Integrate;action=display;num=1204990614

But I still don't fully understand all the ins and outs. One of the examples uses class implementing the Runnable interface, while the other extends the Thread class. What are the advantages / disadvantages of using one method over the other? Also is there anything that those of you experienced in the area would advise to look out for? I'm particularly conscious of sharing large arrays between the threads. Is there a danger of the the fluid solver starting its loop cycle before the camera analyser has finished analysing a frame? On another note, does the run() function get called just once? Or does it loop?

The installation will be outputting to 3 or 4 projectors so the output resolution is going to be pretty massive. At the moment I'm toying between MPE vs. TripleHeadGo type solution. From what I understand, MPE doesn't distribute computing, so even if I have 4 computers rendering only a 1024x768 area each, they still need to compute the whole 4096x768 area? My preference would be the TripleHeadGo type solution and have it all on one multicore computer...

many thanks in advance,

memo.

** UPDATE **
Having read the nice article at http://www.javaworld.com/javaworld/jw-04-1996/jw-04-threads.html
I think I understand the difference between using the two methods, and that I need to create an infinite loop in the run() function with a thread.sleep(..) call between each iteration. But still my other questions regarding advise and interaction between the threads remain!

cheers,

Manic Full Member Offline Posts: 123	Re: another multithreading question Reply #1 - May 21^st, 2008, 10:26am I think (although I don't speak from experience for this one) the easiest way of solving what you're discribing is to set a variable when the camera solver is complete, and then only letting the fluid solver run when the variable is set.

antiplastik

Re: another multithreading question
Reply #2 - May 21^st, 2008, 1:47pm

Quote:

I will be running on an 8-core Mac Pro so would like to spread the tasks into at least 3 threads (camera analysis, fluid solver, main app) if not more.
(...)
Is there a danger of the the fluid solver starting its loop cycle before the camera analyser has finished analysing a frame?

Are you sure you can force a Java Thread to execute in a specific core? Otherwise there will be no need to have so many different Threads for your app, which is sort of linear, though (video capture -> video analysis -> video response).

I found a post about that, but it doesn't mention MAC OS :
http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/30254487.aspx

memo

Re: another multithreading question
Reply #3 - May 21^st, 2008, 2:08pm

@Manic:
Thanks for the tip. One complication I can see is that I need to do the camera analysis every frame, as well as the fluid solver. If I do them sequentially I might as well keep them in one thread. I was hoping I could have the fluid solver run its thing with the data of the previous frame while the camera analyser analyses the data for the next frame. I'm thinking I might need two (or more) sets of data and every frame toggle between the two (i.e. camera analsyser writes data to Array A, while fluid solver reads from Array B. Next frame camanalyser writes to Array B, while fluid solver reads from Array A etc.).

@antiplastik:
I don't intend to tell each thread to work on a specific core - I'm guessing if I have multiple threads the OS can distribute them amonst the cores automatically. You are correct that the app is essentially linear, but I think it would be most efficient if i can distribute the major tasks into their own threads, and have some kind of parallel processing preparing data for the next frame (as I described above).

I've not done anything like this before, and the method I described above (with Array A and Array B) just seemed the logical way to do it, but I'm not sure if it is the most efficient way and maybe there are other established ways of doing these kind of tasks (or maybe even libraries!).

antiplastik

Re: another multithreading question
Reply #4 - May 21^st, 2008, 6:08pm

Quote:

I'm guessing if I have multiple threads the OS can distribute them amonst the cores automatically.

I hope so! :-p

I see Threads as a simple way to tell the main loop : "ok, now, I have to do something (in a separate Thread), but don't mind and keep going".

I would run the camanalyser in the main loop, and once it has analysed a frame, start a new Thread for the fluid solver, so you can keep getting the next images from the camera and analysing them (main loop) while doing your stuff with the last prepared frame (separate Thread).

Pages: 1

‹ Previous Topic | Next Topic ›