Thu, August 5, 2004, 12:00 AM under
MobileAndEmbedded
There are many who believe that the
ThreadPriority property is not available on the .NET CF (some articles, books and MS documentation got this wrong in the past). The fact is that the property
is available (5 priorities like the desktop version - these map to 249-253 in Windows CE terms). However I believe it is a bad idea to change the priority of managed threads.
For every CF application there are 3+1 threads
[Quote from MSFT reply to my question in the ng] :
#1 The main application thread.
#2 is used to control various period timers and timeouts that can be scheduled by the system or applications.
#3 is used to track changes to the active TCP/IP interfaces (simulating the media sense behavior that is present on Windows XP but not Windows CE).
#4 [...] the thread that is used to run object Finalizers. It is created when the first finalizable object is garbage collected.
[Note that the 2nd thread is created only when needed in the CF 2.0 Beta 1]
Apart from the first one you cannot change the priority of the threads above (they are all at 251). So if you change the priority of other threads in your app how will they play nicely with the above four?
When a NETCF garbage collection occurs there isn't a special thread that performs the collection rather it is whatever thread happens to be running when the need for a collection occurs (do not confuse the GC thread with the finalizer thread). What will the results be if that happened to be one of your own threads whose priority you lowered?
Finally, note that the ThreadPool in the CF 1.0 does not have a limit of 25 threads like the desktop framework does; instead it is 256. [CF 2.0's ThreadPool is broken in the Beta so cannot comment on that but is fixed for the next CTP. Apparently CF 2.0 will bring parity with the desktop with a limit of 25. Let's hope that will be configurable]
So if you are going to be creating threads and changing their priority you must first be sure you understand the above and cater for them in your design. I have personally elected to keep all threads at their default normal priority in my CF apps and have only had unexpected results when I experimentally deviated from that policy.