I want to handle threads running in .NET applications using multi-core.
I attempted to call “GetCurrentProcessorNumber” or “CeGetTotalProcessors” of Coredll, but MissingMethodException came back.
I thought that this is because the SMP API is not embedded in the OS of Apalis T30.
In this article, I check the operation of the SMP API on the i.MX6Q platform, but can I incorporate the SMP API in Apalis T30 as well?
Dear @kyas
While WEC7 has full multi-core support built in, the corresponding .NET CF Framework V3.5 does only support single core operation.
The other cores can only be used for native code execution, such as driver code of the OS itself.
If you want to take advantage of all the T30’s cores, you either need to write parts of your performance critical code in C/C++ (which typically boosts the performance of an application anyway), or you need to use WEC2013 along with the .NET CF V3.9, which supports multicore operation.
Regards, Andy
Thank you for your reply.
Since .NET CF 3.5 does not support it, I understood that it is necessary to use native code.
Is it possible to process a thread with another CPU core by calling “CeSetThreadAffinity” using the coredll.dll API?
“CeSetThreadAffinity” needs to pass the handle of the thread to the first argument, how can I pass it?
Although it becomes concrete content of programming, can you tell me?
Hello @Kyas,
The simple answer:
If you are using .NET 3.5 call native code from there and switch the thraed affinity, the software will not work reliable any longer. So we don’t recommend to do that.
The complex answer:
Under some circumstances it may be possible to change the thread affinity. We never deeply tested this but we think it should be working if you change the affinity when you enter the thread and you make sure you changed it back before getting out of the function call. We think that the synchronization is the problem here. If you have a native thread that is running asynchronous, you could try to communicate over message queues, may be this could work as well. But as said we never tested this stuff on our side.
To get the current thread handle, call se the GetCurrentThread function, documented here.
