Unity Threading Helper

[tester]

http://forum.unity3d.com/threads/90128-Unity-Threading-Helper

There is a free version too. Does Multiple Thread work on playmaker?

[jeanfabre]

Hi,

 Threads are advanced features that should be used only when mastering its concept and pitfalls. Without any prior experience on that, I would say that yes it works with playmaker, but having to use different threads is really useful on specific tasks, that I don't think would apply in 95% of the use case for playmaker.

Could you elaborate on where you would like to use threads with PlayMaker? I am quite intrigue by this threading helper, it seems very simple to use.

Bye,

 Jean

[tester]

It is just some ideas. I do not have any critical use case.
It actually should be a playmaker core engine thing.

For FSMs, They do not really have to be synchronized.
Since there should be no dependency between FSMs, other than variable trading, event calling.
I believe It is totally fine to run FSMs in different threads.

In modern mobile device, cpu are often slow. But the good thing is that they are mostly multiple cores.

It is true that FSMs shouldn't be the bottleneck. But It would be a basic things that everyone can take advantage on and scale automatically .






---------------------------------
For the action script use case, pathfinding or zip or gzip for http request(UniWeb library) or anything cpu intensive work would take advantage, so it would not block the main thread. I do see playmaker freeze when doing these stuff. (Again, if It would be an engine thing, this action script would be pointless)

[jeanfabre]

Hi,

 Do you have Unity pro? if you can profile these playmaker freeze, I am sure Alex would be very interested in having access to that. Else if you want me to profile some bottle necks, pm me

bye,

 Jean

[dudebxl]

Any news about this?

I actually used a script with threading in it and I did see a difference. I also have a situation where threading would improve the speed so I would like to test some options.

If i run 2 fsm at the same at the same, are they on different threads?
Can I build a switch or a bridge? For example: Run fsm 1 as thread one and run fsm 2 as thread two?

any opinions on this before my big adventure?

[jeanfabre]

Hi,

 All fsm run in the same thread. Any combination of Fsm and thread would be an experiment at this point, Maybe Alex will shime in with some experience on this. I never attempted this myself.

 I think it will just work fine, if the two threads don't cross datas, so if no global data and no Get/Set Fsm XXX are used to access things from one thread to anoter, I would say there is a good chance that it will work.

 Let us know how it goes.

Bye,

 Jean

[Webbstre]

I'd like a little more info on how to make this work. This is what I have in mind:

Main Thread: Does a few For Loops to go through each XYZ coordinate and either spawn or load data for things in those coordinates.
Side Threads: Spawns the things from an algorithm or loads them from a saved file while the main thread continues through its loops spitting off more simultaneous side threads to spawn/load things.

The best I can think of to compare it to is Minecraft, but with a third coordinate of chunks to check and load from.

[dudebxl]

I am also looking it this. From my understanding at this stage:

You can't spawn/instantiate from a 'side' thread. Has to be from a main thread.
The side thread is more for parallel calculation (and not get component, spawn, transform.position, etc). For example: You have a large loop, then you split it into two and get the 2 thread working on it.

here is an interesting video: https://www.reddit.com/r/Unity3D/comments/2diu3g/multithreading_in_unity/

[dudebxl]

update on this.. not going to happen as too much is not thread safe by unity api so 99.999% of actions will not work.. everything needs to be split in code.. 

[jeanfabre]

Hi,

 Yep... Thanks for having a go at this tho, it's always good to double check from time to time that their might be something overlook to improve performances here and there.

Bye,

 Jean