开发者

moving from 32bit xp to 64bit Win7 - threading implications

开发者 https://www.devze.com 2023-03-14 17:04 出处:网络
We are moving OS and processor architectures in this year. Our current application is not particularly threadsafe, however, it does function poperly on the current specs. We are also moving to .net4 a

We are moving OS and processor architectures in this year. Our current application is not particularly threadsafe, however, it does function poperly on the current specs. We are also moving to .net4 as well.

We are in the process of rewriting the application in a properly threadsafemanner, however this is a multiyear project and we have no choice in the meantime but move the poorly coded system.

My question is this: has anyone been in a similar situation? How can we ensure that we 开发者_JS百科shake out all issue before we go live on the new specs? Is there a good way of mitigating these threading risks? Also, what are the major changes in thread scheduling and behaviour we should be wary of in the move? ThAnks for any assistance


I'm not aware of anything in either the OS or the Framework that would radically change thread scheduling in an existing app. The biggest risk I foresee is that the new CPUs will probably run faster than what you are on now (newer usually equals faster), and this will change the amount of your code that can execute in each time slice your process is given. If one thread hits a wait state there will be more time slice available for other threads to run. Any existing dormant threading bugs could manifest more often as a result of such timing changes. Or you might continue to be lucky. You did not mention this but if you are moving to multi-core hardware for the first time, you will almost definitely see greater concurrency (and therefore risk of collision) within your process.

For mitigation, there's really no good remedy beyond reviewing the shared data/code and properly protecting everything that can be accessed concurrently. If you hit catastrophic problems in testing (you do plan to run full stress and regression before deploying right?), you could consider some kind of 'big lock' at the top of your threads or relevant functions to ensure at-risk code cannot cross paths with its peers. This will probably reduce performance, but high-performing code that crashes all the time is not much use anyway.


As Steve Townsend mentioned, there shouldn't be any significant differences, with a couple of caveats:

  1. Moving from 32bits to 64bits may cause issues because pointers just got larger. That means that you can no longer use DWORD values to hold pointers.
  2. Vista and Win7 are hyperthreading aware. That means that they will be more efficient at scheduling tasks on different logical cores. This might mean you see unexpected context switches which (as Steve wrote) might expose existing concurrency problems in your application.
0

精彩评论

暂无评论...
验证码 换一张
取 消