You didn't explain what you want to accomplish so it's not really possible to answer your questions. But I'll try to elaborate a bit on what is already written on the page you linked.


The script engines share some parts, for example, the thread management, so even if you're having different engine instances in different threads the library still needs to be compiled with support for multithreading to work properly. Calling asPrepareMultithread() sets the shared resources for the script engines. If the function is not called, the first engine instance will make the call automatically. But if you are going to create and destroy the engine instances multiple times you may encounter problems if you do not manually call the asPrepareMultithread() function.


Whether or not you actually need 4 engines is a question for you to answer. I'm pretty sure you can do what you want with a single engine and multiple contexts, but without knowing what it is that you want I really cannot acertain it.


What is shared inside the script engine is controlled automatically by the engine with internal critical sections, so you don't need to worry about that. If you are sure that each engine instance can only access completely distinct sets of data in the application, then there is no need for additional thread safety mechanisms.

From what you're telling me it sounds like you should be going with a single engine instance. You will get no performance benefit with using multiple engines.

As for the contexts, you get the best performance if you reuse the contexts, rather than creating a new instance for each script call. Assuming you'll only have a handful of threads, each thread can maintain its own context throughout the lifetime of the thread, and reuse it for each execution.

asPrepareMultithread should be called only once in the main thread, before any engine instance is created in secondary threads. Still, if you go with my recommendation to use only one engine instance, then you don't need to call asPrepareMultithread at all.


Thanks for pointing out the mistake in the documentation. I'll have it fixed.

No, they will not block each other.

If they are running scripts from the same module you'll have to be careful with the global variables though, as there is no automatic thread safety mechanism to avoid race conditions on accessing those from the contexts.


I'm interested in hearing about your experiences with working with multithreading and AngelScript later on, especially any suggestions for improvements that you may have.

I suspected you were implementing something similar to a web server.

The building of scripts in an engine can only be done one thread at a time. For this reason, you may benefit from using multiple engines, as multiple engine can build scripts in parallel. Loading pre-compiled bytecode is much faster than compiling scripts, but it can still only be done one thread at a time.

Having individual modules for each thread, eliminates the possible race conditions on global variables in the script. Obviously multiple engines will also do this, as each engine will have its own module.

I know a little PHP. I implemented my site with PHP, but I can't say I have a whole lot of indepth experience with it.

Thanks. I'll check in this improvement as soon as possible.