I have spent many years of my career here at Spatial developing Thread-Safe ACIS and now I’ve been given the opportunity to additionally work on the multi-processing infrastructure in CGM. The two modelers use very different multiprocessing technologies, and it has been interesting comparing and contrasting them. The main goal is the same in both cases, to provide a means for our customers to leverage multiple processors to improve performance in their end-user applications.
ACIS is thread-safe, meaning that multiple threads can be active in the same process concurrently. Additionally, all threads share the same virtual address space and hence have direct access to all data. This is a shared memory model. CGM uses multiple processes for concurrency with inter-process communication as a means to share data. This is a distributed memory model. Both have strengths and weaknesses.
Multithreading and a shared memory model not only benefit from direct data access but also from thread-management routines that control thread interactions. By that I’m referring to synchronization primitives that have little overhead because all threads share the same process. (Synchronizing multiple threads is much faster than synchronizing multiple processes). The main drawback to sharing memory is the possibility of data-races (aka race conditions). This is when threads influence each other, usually negatively, by modifying shared data in unexpected ways.
The main benefit of multiple processes and the distributed memory model is that the product does not need to be thread-safe. After all, these are separate processes working independently in their own address space. Inter-process communication is the main drawback. The tasks must be distributed to available processes and the results must be gathered together. This often requires sending and receiving large amounts of data, which is pure overhead.
It has taken many man years of effort to make the ACIS modeler thread-safe. Additionally, we have the on-going burden of keeping it that way. Our entire development team is affected, in that they now follow a strict set of rules to assure correctness. The distributed processing approach is less invasive, in that it can be managed by a relatively small team. Both techniques are relevant and can provide significant benefits when used correctly.
As component software, both ACIS and CGM must supply good interfaces to their multiprocessing technologies. The ACIS infrastructure includes thread-local storage primitives, mutual exclusion logic, and a thread manager that aids in thread creation and task scheduling. The CGM interface, which is still under construction, contains task management with communication logic that optimizes inter-process communications. The code required to utilize either system is not that dissimilar.
Both systems are most effective when used with high-level compute-intensive operations. This is known as coarse-grain parallelism. In contrast, fine-grain parallelism adds concurrency to highly exercised functions at lower-levels, which typically does not provide as much benefit. As such, both systems are intended to be used in very specific and time consuming workflows such as faceting all bodies in a large assembly. In this instance, the multiprocessing overhead is negligible in comparison to the computation time.
The multiprocessing capabilities of our modelers intend to provide an effective means of improving performance by utilizing multiple processors. We will continue to invest in internal uses, for example, the multi-threaded entity-point-distance API in ACIS and the multi-process face-face intersections in the CGM Boolean operator. Additionally, we anticipate more and more of our customers will leverage this technology as the rewards are well worth the effort.
I plan on getting a bit more technical in my next post. Race conditions, for example, deserve a more thorough explanation (and are a favorite topic of mine). I would also like to discuss a few multiprocessing tools, such as Intel Parallel Studio, that are very useful.
