Using Multiple Threads

Parent Previous Next

Using Multiple Threads.

The VM DLL is thread-safe. This allows a host application with multiple threads to load and execute VMs in parallel.


Please be aware though that the integrated trace module for debugging is not thread-safe due to these reasons.


Next are described a few tips and precautions to get the best results.


Access Violations.

The DLL is designed to be thread-safe internally. It means that the shared resources are protected against race conditions occurring from multiple threads trying to access an internal resource (e.g. a global variable) simultaneously.


This does not apply to other resources. For example, if two VMs try to access the same file on disk, you may get an error. Or if multiple VMs uses callback, you must be prepared to protect critical sections within the code of your host application.


The Shared VM.

If a VM is created in one thread and used in another, it is imperative to look at the VM as a shared resource, for which the host must synchronize the "ownership" using an algorithm based on the VM identity number.


VM Pool.

If your host application is a service, which loads the same bytecode to multiple VMs, it might be a good idea to work with a pool of VMs in order to avoid the delay from creating and freeing each VM.


Instead each VM can be reused, if (i) a full garbage collection is done freeing all internal objects, and (ii) all VM cells are cleared.


Please take great care when checking a VM in/out of your pool using a thread-safe algorithm in your host application to ensure each VM is accessed from only one thread at a time.


External Library (Child DLL).

The VM DLL may execute bytecode in multiple VMs, which loads an external library as a child-DLL using the @DllLoad function.


Please notice:


If a child-DLL is shared among multiple VMs in separate threads, it can be a problem to decide when to safely call the @DllFree function to unload the child-DLL, because one VM may free it, while another VM may still need it.


The simplest solution is to never free a shared child-DLL.


An alternative is to let the host be informed by each VM about when the child-DLL is no longer required. Once all VMs have reported back, the host can initiate having a VM perform the DLL unload.