Posted on 05/21/2012 6:20:42 AM PDT by varmintman
Somebody has an ordinary MFC program which uses one or more separate threads to handle disk-intensive activities (AfxBeginThread ( additems, pstr , THREAD_PRIORITY_NORMAL ) or something like that), and he goes out and buys one of the new computers with an I7 chip in it which are now under a thousand dollars USD.....
Assuming he is also using VisualStudio 2010, what exactly happens? is Win 7 bright enough to assign separate processors to separate threads when possible, or do you need to set some build parameter differently from past ages, or do you need a copy of Intel's rich-only-need-apply C++ compiler, or what exactly.
I'd appreciate hearing from anybody who's actually seen this one or has any sort of a clue.
Sorry. I’m the right guy but my multithread under 2010 is limited. I’d ask Doctor Google.
.Net may or may not be an option here, not sure. The main dll has to stay MFC, performance concerns as well as concerns with how easy the code would be to disassemble. The part which does threading however is separate from that and converting it to .Net might work if there’s no way to get to using an I7 with MFC code.
I ain’t a C++ head, but if you have source, isn’t it nearly a nobrainer to compile to C#? I mean, yeah, pointers and garbage collection, but other than that?
The Background Worker is the new preferred way from what I was reading. With respect to thread dispatch on individual processor cores, you should be able see processor demand curves in perfmon?
I have a multi-threaded c# application I’ve been hacking on for several months, and several things I have noticed in VS 2010 is that debugging is definitely not linear. In fact, the only way I have been able to effectively debug is with log statements. I had to do use lock on a readonly object to single thread through the logger, but it seems to be effective, more or less. At least I’ve been able to generate the application, thank goodness...
The interface code could be converted to C#, the function code couldn’t, again performance and P code being too easy to disassemble and then a lot of bit fiddling in code which is more like C than C++ and the C functions probably aren’t there in C#.
If the drain is large enough, I suppose.
I have a multi-threaded c# application I’ve been hacking on for several months, and several things I have noticed in VS 2010 is that debugging is definitely not linear. In fact, the only way I have been able to effectively debug is with log statements. I had to do use lock on a readonly object to single thread through the logger, but it seems to be effective, more or less. At least I’ve been able to generate the application, thank goodness...
There are a series of pretty good tips on debugging MT apps:
I'm not a 100%, but I'm almost willing to bet you that they are.
C# is VERY rich, VERY robust.
From what I know C# and .Net handle this. C++ API call has an Affinity Mask that assigns a core when you create the thread.
GOTO Here: http://www.dreamincode.net/forums/topic/52380-multi-threading-on-multi-processors/
Thank you for the multi-threading debug info... now that i understand how to switch threads in the debugger it helped to identify and protect a couple synchronization fixes. Also it is very interesting how you identify thread demand as drain. Do you derive that from the sink /drain programming concepts in Windows? It caught my eye mostly because we describe cpu demand in increasing, or utilization terms. I was wondering about how drain describes it in decreasing, or approaching idle. Do you work in UNIX java environments or do you specialize in Win/.net?
I’m a dot Net guy... glad you got something out of that...
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.