A single application only has access to a single MCR computational engine. This is guarded by a process wide lock, so multiple components cannot access the computational engine simultaneously.
The setting for "object instances share MCR" in DEPLOYTOOL or the "Create Singleton MCR" (-S option) of the MCC command does not affect this limitation. These options only control the MATLAB environment, i.e., workspace, in which the code will execute, not whether they share a computational engine.
The only way to work around the limitation of a single computational engine is to create a second process (for example, by running a second instance of your executable). Alternatively, our MATLAB Production Server (MPS) product (
) can help facilitate use of multiple MCR computational engines in this way by providing infrastructure for out of process MCRs (MPS workers).
Consider an application "myApp" which creates instances of classes from multiple .NET Assemblies created by MATLAB Builder NE. All instances of the classes will use the same computational engine. This is similar to calling all the MATLAB files one after the other in the same open session of MATLAB.
However if you run two executions of "myApp" at the same time, each process will have its own MCR computational engine because they are separate processes. This is similar to calling the MATLAB files simultaneously in two distinct sessions of MATLAB.
On a single processor or single core machine, creating a second computational thread in many cases will not realize any performance improvement, as the processing power of the computer is limited by the single processor. On a multi-core/multi-processor machine, however, having only one computational engine is a bottleneck.
