Sorry for the late reply, but I had to chime in here: It is a common misunderstanding, unless an instruction is designed to be atomic (like x86 CMPXCHG or 680x0 TAS), an instruction can be interrupted mid-execution (e.g. INC [mem] can be interrupted after the read and before the write of the incremented value. This moment would be considered interruptible even tough the operation is not completed). If you need guaranteed atomic operation, you have to either use an instruction that is designed as atomic or you have to implement an access control mechanism that is based on these atomic operation around your non-atomic operations. Semaphores etc. are based on these guaranteed atomic operations to guard complex, i.e. non-atomic, operations. On a side note, this concept becomes even worse when executing with multiple CPUs or cores where several instructions are executing simultaneously and they can interfere with each other even without preemption. In this situation atomically-designed operations still guarantee atomic execution while others are becoming indeterministic as they are executed in parallel.

Sometimes the execution order does not matter, but the publishing of the result (e.g. if your processing takes significant time before results are available). In this case you should spinup the threads and let them execute in any order as they will, but when the results are available wait for the completion of the "previous" thread and then publish your results. Using a pattern like this would allow to use the parallel execution of the long processing and still have the serialized behavior at time of the publishing of the results.

Threading is not deterministic in the order of execution unless you add constructs to synchronize your threads, e.g. Thread 2 waits for completion of Thread 1 before it starts, Thread 3 waits for completion of Thread 2 before it starts, etc. But that would defeat the purpose of threading, if you create threads to allow parallel execution, but then you serialize all of their execution. (On a multi-core machine, they can even be scheduled to execute physically at the same time, which opens up a can of even more indeterministic behavior ;) )

Hi Kiran, I ran into the same problem some time back, a communication link had a 5-baud initialization sequence where communication parameters were negotiated. Unfortunately we did not find any UART that supported this reliably. So our solution was to use a GPIO pin combined with a UART, implement the 5-baud initialization by sampling the GPIO input and after the negotiation switched the GPIO to high-Z and enabled the UART, now with a supported, high baud rate. Hope this helps.

The problem is the lambda expression, it references the variable i of the outer method at the time of the thread execution, and that is likely after all threads are created. This is not like a passed parameter that gets copied at the time of the thread creation. Try creating a thread that takes a parameter and pass the i there, this should resolve the issue.

Take a look at the AForge.Net framework, it has a component for this kind of algorithms: AForge.NET Framework This is the namespace you might be interested in: •AForge.Genetic - evolution programming library;