Is DWScript thread-safe?

Question

I would like to know if DWScript is capable of using threads inside of scripts, as some engines do not synchronize access to it's internal data structures.

Answer 1

Arnaud gave the key points:

• each compiler instance can only be invoked from one thread at a time. You can have multiple compiler instances invoked in multiple threads at the same time, and a particular compiler instance can be used from multiple threads, provided only one thread uses it a time.
• each compiled program can have multiple executions, each execution can be running in its own thread. Also a particular execution can be used by several threads, provided only one thread uses it at a time.
• each executions has its own space for its variables, and its own stack, object instances are on the heap and can technically be shared across executions, there is no locking mechanism for that, but you could make your own.
• the script engine does not perform any synchronization or locking when using classes or functions exposed to it (be it via TdwsUnit, RTTI, etc.), so when running script executions in threads, make sure you only exposed thread-safe stuff (be particularly careful about that for RTTI, since lot of the RTL & VCL is not thread-safe to begin with)

Running multiple executions of a script is similar to having multiple threads in Delphi, though each new execution has not only its own stack (like Delphi threads) but also its own variable space (in Delphi it would be a bit like if you had "thread var" everywhere). And DWScript executions don't have to be in their own thread, they can be moved across threads, or polled and used in a lower number of threads (the only limitation being that each execution is used by only one thread at a time, as mentioned above).

So nothing prevents you from exposing a function that would spawn a thread (and corresponding execution) in a script function, but communication across the executions wouldn't be via shared variables (like you could be tempted to do in Delphi), but would have to go through your own exposed functions (or external variables), return values (using an "evaluate" approach, cf. the unit tests), "shared" object instances, or "global vars".

By "global vars", I mean the functions defined in dwsGlobalVarsFunctions.pas, which can be used for inter-execution data exchange. To activate them, just have a "uses dwsGlobalVarsFunctions" somewhere in your project.

They expose a set of Read/WriteGlobalVar functions, which allow storing and retrieving named variants across all script executions running within the same Delphi process, and those reads & writes are "atomic" from a threading point of view.

Answer 2

It was not even necessary to open DWS documentation. :)

Just take a look at this StackOverflow answer by Eric:

For instance, [DWS] is now capable of multiple thread-safe executions of a single compiled script, while the old codebase is built around the limitation that a compiled script can be executed by only one thread at a time.

In short:

• The DWS compiler is not thread-safe: you have to create the execution stack within one thread (you can't share a compiler instance, you need one thread per compiler instance);
• The DWS execution is thread-safe, if you use one execution instance per thread: you can run the same compiled script in several threads;
• Communication between threads are not available AFAIK, but you may use Delphi code if you need synchronization.

Of course, here is the official documentation page about thread safety in DWS.

You can now have as many program executions for a given IdwsProgram as you wish, each execution will use memory for its heap & stack only, the compiled expression tree is shared. Both new interfaces use reference-counted memory management.