Obtaining the magic NumThreads setting for a LOWIS server process

LOWIS Server processes operate in a shared thread processing model, where there is only one "active" thread at a time while the other threads might be in a suspended state waiting for a reply.  In each layer of processes (Processors,Scan Tasks, or Communications Tasks), pending tasks on are divided based on the Communications Port they will ultimately be processed on.   So, for example, if there are beam wells on COM1, COM5 and COM7 and injection wells on COM5 and COM6, then there will be at most 3 worker threads in use on the beam processor and 2 worker threads in use on the injection processor.  This division comes from the days of serial based device access, where only one device at a time could be communicated with on a communication channel, so there was no point in trying to process more than one item of work at a time for a given communication.  When a worker thread has prepared its request for the next level down in the hierarchy and has sent it out, it goes into a wait state until the reply is received.   While it is in this wait state another worker thread is allowed to process its work, allowing for a controlled pseudo multi-threaded mode of processing. 

As these worker threads are allocated by Communications Channel, there is no benefit to having more threads allocated than are needed for the communications threads.  LOWIS processes allocate a few threads for non communications based processing (scripts and reports as examples), so the general rule is to have

NumThreads = 3 + number of communications ports to be talked to

For the examples mentioned earlier, this would mean a NumThreads value of 6 for beam processor and 5 for injection processor.  Note that this is different that what would be expected in a true multithreaded application, where the general rule is to only have a maximum thread count equal to the number of actually available processor cores in the computer as any more would imply switching out active threads to run other threads.

IsParallel

In the early days of LOWIS, OPC communications were handled in the mscan program along with the other communication methods.  In this case it was typical to setup multiple communication ports talking to the same OPC server to provide a mechanism to spread out a scheduled scan to allow it to be completed faster.  When the OPC Manager system was created, these communication ports were effectively collapsed into a single communication port, meaning that these scheduled scans were now taking longer, even though both OPC Manager and the OPC Servers are fully multi-thread capable. 

As a result, a new option was created (IsParallel in the Server section of the Configuration system) that turns off the system in LOWIS processes that distributes items to be worked on based on the final destination communication port and instead assigns the items of work to a thread as soon as a thread is available.  The benefit of this is that for scheduled OPC scanning (which should have a near zero millisecond turnaround time) LOWIS can process scheduled scans very quickly.  The downside is that if any non-OPC communication methods are in use, the entire processor will be waiting for threads to become available since they are now all occupied where with the communication port allocation they would all be on one thread's queue.  This will turn that process into a complete bottleneck for all tasks.

In general, we only recommend turning on the IsParallel option for purely OPC systems, as significant processing impacts can occur in other communication environments.  Please note that IsParallel should only be turned on at the Server level entry of the configuration system, it should not be enabled/disabled on a processor basis.