Let's discuss the benefits of parallelization with the help of a little sample task. Let's say we have hundreds of shapes like those three up there, that we generated procedurally. Furthermore there are randomly created points on the edge polygons of these shapes. We want to connect these points to each other so we get a continous spline. Because the points were generated randomnly, they are not in the correct order. Our goal is to bring these points in the correct order and generate a spline. For now we concentrate on the blue circle. To complicate things a little bit we distort the circle to a certain degree in the X-direction. We get the following points. Because this is an illustrative example, we remain in the two-dimensional space.

As you can see in the image and in the table we have to reorder the points before we can connect them to generate a spline. At first sight it seems to be a simple task. We stick together some nodes in TP that search for the nearest point.  But this would be a very error-prone approach, that rarely leads to the correct order. As trying all permutations is impractical (see also TSP in general) we instead implement Simulated Annealing with the 2-opt algorithm as the local search algorithm. In this way we will likely obtain the global distance minimum.  For hundreds of shapes (with e. g. 500 points each) this leads to a reasonable computation time (single-threaded as well as multi-threaded).

What you can see on the right is the essential part of the implementation of the algorithm in C#. Ideally, we want this code to run on a separate thread for each shape. I encapsulated some parts of the code like the actual swap in the PathHelper class living inside the TP namespace.

As you might have also noticed I chose a fixed cooling rate of 0.95. Thats why no cooling rate parameter is exposed to the Thinking Particles UI.
The else statement ensures that we can escape from local minima (assuming we have chosen appropriate initial parameters). The acceptance probability is defined in the else statement as euler's number raised to the power of the paths difference (negative) divided by the temperature.

There are a couple of steps involved in getting the multi-threaded approach working. First you need a TP script operator. This operator converts all the data the DLL needs to perform the multi-threaded task. Then you call the function of the DLL and retrieve the data so the particles can further be manipulated within the script operator. The various steps we have to take:

1. Create a TP script operator
2. Convert data where necessary
3. Write a multi-threaded DLL and compute computational intensive tasks therein
4. Send the data back to the TP script operator
5. Manipulate the particles

Keep in mind that it can be beneficial to use the server garbage collection mode. (This can have a huge(!) effect on the CPU core usage.)

Writing a custom TP a basic script operator isn't to difficult. Joe Scarr has some great ressources out there you can follow along to get you started (e. g. here).

A TP script operator for our use case of reordering particles may look like the one on the left. As we are going for a multi-threaded approach we need to store the ID of each shape - here in the parameter tab called "Parent ID" (data channel 0). This way we are prepared for using one thread per shape (in case the TPL decides so or we force this degree of parallelization). Additionally we can provide our Simulated Annealing algorithm with an initial temperature and an exit condition (max iterations). We have to set the initial temperature high enough to escape local minima, an acceptance probability of 0.8 could be a first step.

DotNet values are not Maxscript values and vice versa. Before you send data to your DLL you have to check wether the data type is supported by .NET or to be more precise you have to check wether Maxscript is able to automatically convert the data type to its .NET counterpart. For your convenience you can find a table below containing all automatic conversion possibilities:

When working with particles we typically store three dimensional vectors as Point3 (Maxscript-)values. As you might have noticed Maxscript cannot convert this type to a .NET counterpart automatically. But it can convert (jagged) arrays of the type float. As the Point3 class has the x, y, z coordinates as properties, we can convert the Point3 type to an array of floats and send a jagged array of the type float to our DLL.
There are also other ways to deal with the issue of conversion. For example you could convert the Point3 type to a Vector3 type directly in 3ds Max using the "dotnetobject" syntax, or to give you another example you could make use of the Autodesk.Max DLL (IPoint3).

You can create the DLL in the IDE of your choice. For C# projects I usually work within Visual Studio. It is advisable to import the "System.Threading.Tasks", "System.Linq" and the "System.Collections.Concurrent" namespace as a base for working with particles and multithreading. The following steps are involved in the creation process of the DLL: