🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Thread safety
Author
I'm considering using AngelScript is a multi-threaded environment. Specifically, with the following constraints :
There is a single ScriptEngine shared among N threads.
No script in the same module will be executed by two different threads at the same time.
Thread A might attempt to compile a module while thread B is executing code in a different module.
Have these situations been accounted for and tested?
(As an aside, does the ALLOW_UNSAFE_REFERENCES stuff still work like it did with 2.0? I just want to make sure I can continue to use the library like I had before, or if I'm going to have to use an old version.)
ALLOW_UNSAFE_REFERENCES still work. Though now it is a dynamically set via SetEngineProperty.
AngelScript with multithreading has not gone through a lot of testing. Though users have reported that it works quite well.
It shouldn't be a problem having a script being executed in one thread while another thread is compiling a module. Having two threads compiling different modules at the same time will not work though.
AngelScript with multithreading has not gone through a lot of testing. Though users have reported that it works quite well.
It shouldn't be a problem having a script being executed in one thread while another thread is compiling a module. Having two threads compiling different modules at the same time will not work though.
Author
So I'll have to serialize compiling. Can I safely assume that creating a context, setting global variables in a module, or executing a script do not modify the IScriptEngine, and are thread safe?
I'll be letting you know if I encounter anything.
I'll be letting you know if I encounter anything.
Setting global variables in modules or executing scripts do not modify the script engine.
However, do not execute two scripts in the same module in separate threads, nor set global variables in one thread while executing a script from the same module in another thread. Simultaneous access to the same module is not protected by the engine, and must be controlled by the application.
Please do let me know if you encounter any problems. AngelScript should fully support multithreading, but without a proper project it is very difficult for me to validate this.
However, do not execute two scripts in the same module in separate threads, nor set global variables in one thread while executing a script from the same module in another thread. Simultaneous access to the same module is not protected by the engine, and must be controlled by the application.
Please do let me know if you encounter any problems. AngelScript should fully support multithreading, but without a proper project it is very difficult for me to validate this.
Author
Well. I might have a problem then. I was going to use script classes such that each script would define one class, which I would instance and call methods on. The classes would corrospond to modules 1 to 1. The modules would have no global data, but multiple threads could execute the class methods at the same time. If that won't work, the alternative is to do it the way I had before, and duplicate the module for every single instance. (That's a big performance hit, especially with the memory usage.)
Well, if the modules doesn't have any global variables, then you should actually be able to have multiple threads execute scripts from the same module without any problems.
I'm updating the AngelScript documentation with all these points discussed so that others can benefit from them.
I also got some ideas for some minor improvements from this discussion:
1. The engine should protect against multiple threads trying to compile scripts simultaneously, i.e. if a script is already in the process of being compiled when Build() or ExecuteString() is called, then the method will fail, and the application may try again later.
2. Applications should be able to dynamically disable/enable global variables in scripts through an engine property.
Regards,
Andreas
I'm updating the AngelScript documentation with all these points discussed so that others can benefit from them.
I also got some ideas for some minor improvements from this discussion:
1. The engine should protect against multiple threads trying to compile scripts simultaneously, i.e. if a script is already in the process of being compiled when Build() or ExecuteString() is called, then the method will fail, and the application may try again later.
2. Applications should be able to dynamically disable/enable global variables in scripts through an engine property.
Regards,
Andreas
Author
Would it be possible for the behavior of option 1 to also depend on an engine property? I can see a need for it to return immediately; but it could also be useful for it to block.
For 2, global data is 'disabled' already because I'm doing that thing discussed in the cloneable modules thread.
I'm going to have a look around the source myself, to see if any race conditions or such pop out at me.
For 2, global data is 'disabled' already because I'm doing that thing discussed in the cloneable modules thread.
I'm going to have a look around the source myself, to see if any race conditions or such pop out at me.
Well, I had thought about doing it like that at first. But I don't think I'll add that as a built-in option. If you want to have the threads wait for each other it is better for your to implement that in the application itself.
Yes, in your case global variables would be disabled, but this would more be an option for those that do not use the same solution as you yet still needs to avoid script writers to use global variables.
Yes, in your case global variables would be disabled, but this would more be an option for those that do not use the same solution as you yet still needs to avoid script writers to use global variables.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
