• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
thewavelength

Threading of multiple engines

9 posts in this topic

Hello,

I'm about to create a threaded environment of totally seperated engines.
I found this page in the documentation: [url="http://www.angelcode.com/angelscript/sdk/docs/manual/doc_adv_multithread.html"]http://www.angelcode...ultithread.html[/url]

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
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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 :D

Thanks!
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0