9 replies to this topic

[thewavelength]

Hello,

I'm about to create a threaded environment of totally seperated engines.
I found this page in the documentation: http://www.angelcode...ultithread.html

It says something about threading, but I don't think this matches my situation.
I want to have about four totally seperated scripting engines which DO NEVER come in interaction with another engine.

Another question is: DO I need four engines? Couldn't this be solved using four contexts?

Also, the scripts are allowed to access only thread local variables and functions.
So I am doing right with not implementing thread-safety mechanism?

Are there other points I have to look at?
Thanks!

Edited by thewavelength, 17 September 2012 - 02:40 AM.

[Andreas Jonsson]

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.

[thewavelength]

Hello,

thanks!

My situation is, that in one process there are four or more threads (the size is fixed). Now I invoke a call to one (randomly selected) thread that it shall execute a script.
This script is only used once per time. Means: when the script has finished, the context shall be deleted. Everything should be cleared as if there were no running scripts before.

I don't need modules. I don't need sharing between different scripts. I only need the #include-preprocessor command (which works well).
The question for me is now whether it's more clever to use one engine per thread or to use only one engine...

I think one engine per thread is a bit faster because I don't need to wait on mutex releases when I create a context... Since I'm not very experienced with AngelScript and threading in general I can't give a final answer to this question.

Thanks in advance :-)

Edit: I've found another issue.. What if I decide to start a fifth thread because I've got a lot of requests? How do I handle with asPrepareMultithread then?

Edit 2: There's a mistake on the documentation page http://www.angelcode.com/angelscript/sdk/docs/manual/doc_datatypes_strings.html -> string str1 = "This is a string with \"escape sequences".";

Edited by thewavelength, 18 September 2012 - 06:15 AM.

[Andreas Jonsson]

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.

[thewavelength]

Oh, okay.
So the contexts will not block each other when they are running in different threads though they are using the same engine?
Be sure that this is my last question

Thanks!

[Andreas Jonsson]

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.

Edited by Andreas Jonsson, 18 September 2012 - 09:05 AM.

[thewavelength]

Hi,

Ok, thanks for your fast reply.

Since I'm currently rebuilding the whole module before I run it, I shouldn't have problems with race conditions.

Will these problems still exist if I use different engines? I don't think so.

About my plans: I try to make AngelScript usable as a web scripting language. It works via fastcgi or scgi in a single application. The application implements a process spawner to allow real-per-user script execution. This improves security and performance. Then every spawned process runs under a real user, holding some threads. Currently there are as many threads as cores provided by the CPU. It also contains a load balancer. If a certain amount of requests is longer than 0.2s in the processing queue, a new thread will be started. The thread pool decides by itself when to reduce the number of threads.

Currently, a context is created once per thread startup and is reused for every request in the specific thread.

To allow much better experience with AS as a scripting language, I'm about to rewrite the whole preprocessor. It contains a bit more flexibility and is more dynamic.

I don't know if you know PHP. If you know, you may know its mistakes and problems. I think that a lot of mistakes could be solved using AS, including caching and security improvements.

[Andreas Jonsson]

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.

[thewavelength]

Hey,

ok. Thank you

Btw, I found a possible optimization. Because I don't know where to put this, I may write it here.
In scriptstdstring.cpp, lines 91 and 92 (speaking of 2.25.0) could be replaced with:
[source lang="cpp"]it = pool->insert(map<const char *, string>::value_type(s, string(s, length))).first;[/source]

Bye.

[Andreas Jonsson]

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