iNTERFACEWARE™ Inc.

Multi-Threaded Applications Can Be Slower

Unless you are in one of the rare situations in which you have a server with multiple CPUs, having multiple threads can slow your application down because of the overhead of changing thread contexts.

The reality is that there is usually only one processor in your server that is switching between several threads. There is overhead that comes from that processor having to change context for each thread. That uses up processing time that could be better spent performing the actual task on hand.

A poor multi-threaded design will result in concurrency issues and thread conflicts that all consume CPU cycles. Many of the operating systems state that a multi-threaded application needs to wait on other threads, locking critical sections and are often quite expensive.

For this reason iNTERFACEWARE does not put thread locks around Chameleon engine objects for parsing. If thread locks were put in place, this would affect the performance of HL7 interfaces that are not multi-threaded. If you are using multiple threads with Chameleon, you must ensure that two threads do not enter the same instance of a Chameleon engine object at the same time.

	Multi-threaded applications with Chameleon should either: Put a critical section around each Engine object to prevent multiple threads from accessing the object at the same time, or Ensure that each thread has its own instance of an Engine object, which only it can access. This will probably result in better performance.