I had to use Callable for each attach/deatch method call when it is not called by main thread.
So I suppose a method to guarantee thread safety at attach/detach nodes
(Not perfect but much more reliable than now)
My approach is using method like double buffer.
When attach/detach is called, it is modified at back buffer
and copied to front buffer when updateWorldData() is called.
patch file is attached (too long)
Its a good idea, but I’d say we don’t commit it. First of all its overhead hard coded in the engine where it doesn’t belong, especially if the game doesn’t use multiple threads. The developer should take care of thread safety, not the engine. I use AspectJ for that and it works like a charm and doesn’t pollute the code.
similar issues (one of them risen by noone other than me ;)):
http://www.jmonkeyengine.com/forum/index.php?topic=9675.0
http://www.jmonkeyengine.com/forum/index.php?topic=11929
I would say firstly it needs to be profiled and determined exactly what the memory and computational overhead is. If it doesnt make a difference its not a bad contribution.
But in general I've found that re-using nodes also isnt a bad way of implementing threaded attachments (hoever its not real attachments and detachments).
dhdd said:
Its a good idea, but I'd say we don't commit it. First of all its overhead hard coded in the engine where it doesn't belong, especially if the game doesn't use multiple threads. The developer should take care of thread safety, not the engine. I use AspectJ for that and it works like a charm and doesn't pollute the code.
Okay. I just thought that the attach/detach doesn't occur frequently so it wouldn't affect the performance.
Anyway, I need to study AspectJ. Interesting!
mulova said:
Okay. I just thought that the attach/detach doesn't occur frequently so it wouldn't affect the performance.
Anyway, I need to study AspectJ. Interesting!
Hold your horses, its not over yet, it was just my opinion ;) Maybe one of the elders wants it in. :)
BTW: AspectJ is always worth lerning :D
As JME 2 wasn't designed with multithreading capabilities, I'd also prefer this out for now.
jME is not really compatible with multithreading at this point. With many static temporaries and such it is not guaranteed to function at all when invoked from another thread. So although things like this could help, it is still best to interact with jME in only one thread.
jME3 will provide some better support for multithreading, and AFAIK Ardor3D is on that route as well. Both of these engines have no static temporaries so that's quite a large step right there.
Momoko_Fan said:
jME3 will provide some better support for multithreading, and AFAIK Ardor3D is on that route as well. Both of these engines have no static temporaries so that's quite a large step right there.
I'd like to use jME3 / Ardor3D as soon as possible. :D
Thank you for the all advices. I'll using this patch just for my project.
mulova said:
I'd like to use jME3 / Ardor3D as soon as possible. :D
Thank you for the all advices. I'll using this patch just for my project.
jME3 will take a bit for production use and Ardor3D ... well ... we'd rather you didn't ;) If you need AspectJ help (or even an aspect that does solve the problem above, just let me know.
dhdd said:
jME3 will take a bit for production use and Ardor3D ... well ... we'd rather you didn't ;) If you need AspectJ help (or even an aspect that does solve the problem above, just let me know.
Thank you for your kindness.
Unfortunately, our project is not based on AspectJ.
But after finishing this project, I'll study AspectJ and ask about this.
Good day~ XD