Microsoft on Multithreading
-
Hear, hear!
Change of fashion is the tax levied by the industry of the poor on the vanity of the rich Fold with us! ¤ flickr
Hey its called Visual BASIC(Beginner's All-purpose Symbolic Instruction Code. ) Its was designed as a teaching tool. It obviously works. The problems arise because its often self taught so the student learns nothing about good design and structure.
When prediction serves as polemic, it nearly always fails. Our prefrontal lobes can probe the future only when they aren’t leashed by dogma. The worst enemy of agile anticipation is our human propensity for comfy self-delusion. David Brin Buddha Dave
-
WOW... so many angry VB ... programmers.. coders.. how do you call yourselves these days ? Shog... i'd be careful if i were you... maybe they'll find (not program, FIND.. on the internet) some control which will make you regret your words! :laugh: Come on guys, what's the big fuss about? VB is a toy.. never was never will be anything more than a TOY for programmer wannabes and "hackers" ... deal with it! ( or learn to program :laugh: )
A buffalo soldier, a dread-like rasta !
We are not angry, we have gone home for the weekend. :) Our Program is done while you C-people are still writing your string-class! You are just grumby because of all the overtime spent debugging your pointer-spagetti and jealous because we can make applications faster and cheaper. No one will pay you for writing that string-class and other sub-modules over and over.
-
Have you used the windows file folder UI? At least you can't fault them on not practicing what they preach.
This blanket smells like ham
-
OK Lets not all get carried away. VB is not the best language in the world. We all know that. But it did introduce me to programming. I soon found it's limitations and my quest for knowledge lead me to c++,ruby and c#. However, vb did give me a way into a subject that I may otherwise not have been able to participate or gain emplyment in. I didn't go to University but instead have worked my way up through the development world. My day jobs have seen me hold interesting and callening positions for various companies including banks like HSBC. The projects I have worked on have not been "simple data entry" screens and the languages used have at times included vb. My spare time sees me develop code for KDE and related projects. None of which I would do had I not picked up VB. To be fair and honest I have moved away from VB now and mainly get paid for c#. But I don't think VB bashing is really fair or constructive. Does anyone bash you for your choice of clothes of car?? No back to the original post. I think developers need to realise that ignoring threading going forward with the new mutlicore chips will be a massive mistake. For too long people have looked to the hardware for speed boosts and now the resposibility for the speed boost will lay at the developers door. Those developers that do not learn to debug "hard" mutlithreaded apps will be left behind and look to have outdated skills. I for one am looking forward to learning these skills......
Oh, uh, good question. Now technically speaking, uhh, let's say, put me down as a... 'Whatever'?
Does anyone bash you for your choice of clothes of car??
Well, actually, Yes they do. But I like good will, and 20 year old Corollas
MrPlankton
-
What's really sad is you probably believe that.
...and he is probably a hiring manager. But this thread is interesting in that it shows what to emphasis on a resume and hiring interview and apparently vb is probablematic.
MrPlankton
-
logan1337 wrote:
"Because multithreaded programs are complex and difficult to debug, they should be avoided when single-threaded solutions exist."
I suspect that technically there is always a single threaded solution. The problem is that the end user may not like the "solution" since in many cases the UI would become unresponsive. Writing multithreaded applications can be hard and in my humble opinion many "programmers" haven't really understood the basics of it and that causes troubles in terms of applications that hang and so on. I consider multithreading a powerful tool in the programmer's toolbox, but I've also experienced that people doesn't know how to use the tools in the toolbox even if they refer to themselves as programmers. If I need a carpenter and it turns out he doesn't know how to use a screwdriver, I wouldn't trust him to build my house/bookshelf/whatever even if he calls himself a carpenter. On no way is this a malfunction of the screwdriver. All kind of screwdrivers are available on the market and anyone can buy them, but the know-how of how to use the screwdriver isn't included in the purchase of the tool. If the screwdriver manufacturer published a proclamation that said "screwdrivers may damage the head of the screws, use our hammer instead if possible", I would certainly doubt any carpenter that claimed this proclamation to be a good advice since I would conclude that he apparently doesn't know how to use a screwdriver. Of course it's always technically possible to use a hammer instead of a screwdriver, but that would cause unwanted side effects that are obvious to skilled carpenters.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownI think threading is much more common (or it should be) and a required skill for any programmer since something as mundane as a progress bar lends it's self to a multithreading solution.
MrPlankton
-
Because multithreaded programs are complex and difficult to debug, they should be avoided when single-threaded solutions exist. I would add that when a single-threaded solution does not exist, try to make your multithreaded solution look as much like a single-threaded solution as possible. This usually involves making sure each thread owns its data and communicates with other threads in a thread safe mannor, i.e. events, messages queues, etc. Beyond that you have to put locks in the appropriate places to protect shared data, which is ok, but the complexity increases fairly quickly in that case.
I agree. If you must do multithreading, don't use locks. Instead, opt for message passing and queuing.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: The Lord Is So Good The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
logan1337 wrote:
when single-threaded solutions exist
I think I'm going to just quietly rewrite all my use-case requests. No one will notice. "Responsive UI? Nah - we decided against that" "Efficient and speedy multiple network connections? Overrated." The "when single threaded solutions exist" is a kicker of a subtle details here.
cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
The "when single threaded solutions exist" is a kicker of a subtle details here.
Um, don't single threaded solutions ALWAYS exist? Unfortunately in Windows, the UI is the single thread. If you do any lengthy processing, you have to spawn another thread so the UI doesn't appear to hang.
Gary
-
dear mister shog, i don't know if you ever been abused by a vb programmer, but what is the f*cking use of the reaction it ads no additional insight in the real question... should multi threading be avoided when possible. so please refrain from talking if it not useful ! (o yeah I'm not only a vb programmer, i do c, c++, c#, java, vb, php) life would be beautiful if other ppl won't try to disrupt the sheer beauty of it. o yeah, I'm a firm believer that a lot of programmers like to make code more complicated, just to make it interesting for other programmers to look at, but has no functional benefit whatsoever. so the sentence is correct only, if it should be in this article .. no it just a good practice to make code as simple as it needs to be. -- modified at 1:52 Friday 16th November, 2007
Absolutely. I've coded simulations for 10M worth of HPC hardware, I've coded realtime firmware, I've coded simple win forms in VB, essentially I've touched the whole concurrent spectrum. Concurrent code is a lot harder to debug. Up until recently most coders weren't really coding concurrency (if you are time sharing 1 CPU you only have one thing running at a time regardless of the number of threads), and few coders, even good ones, can do it well. Confucius say "he who uses multi-threading when not needed shall be cursed to spend weekend debugging". This is common sense. MS isn't saying don't multi-thread/multi-process, just don't go out of your way to do it. Ex. if the calculation takes a tiny fraction of a second, why worry about freezing the users window for that time? Same thing goes with recursion. There are few cases were its use is the most intuitive way to solve the problem, so why go out of your way to use it and suffer during testing? The easiest to code, and to read method for most programs is the way to go. Otherwise you pay for design time, you pay for coding time, for testing time, and extend the learning curve of new hires. With complex designs you keep paying and paying. Its alright if you need that last ounce of performance (eg. game development, DBMS etc), but most don't.
-
Chris Maunder wrote:
The "when single threaded solutions exist" is a kicker of a subtle details here.
Um, don't single threaded solutions ALWAYS exist? Unfortunately in Windows, the UI is the single thread. If you do any lengthy processing, you have to spawn another thread so the UI doesn't appear to hang.
Gary
ghle wrote:
don't single threaded solutions ALWAYS exist?
I guess you could always do lots of Peek & Pump Message calls... X|
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
Hmm, so that is why Visual Studio works on one processor only? Sometimes I find myself imagining that maybe one of the next versions might make use of my dual core, and not make me wait for 15 minutes or more because it's too complex and difficult to spread the compilation and linkage of 5 projects onto 2 processors. Maybe that is too much to hope for :sigh: What again are multiprocessor systems good for? :rolleyes:
-
logan1337 wrote:
"Because multithreaded programs are complex and difficult to debug, they should be avoided when single-threaded solutions exist."
I suspect that technically there is always a single threaded solution. The problem is that the end user may not like the "solution" since in many cases the UI would become unresponsive. Writing multithreaded applications can be hard and in my humble opinion many "programmers" haven't really understood the basics of it and that causes troubles in terms of applications that hang and so on. I consider multithreading a powerful tool in the programmer's toolbox, but I've also experienced that people doesn't know how to use the tools in the toolbox even if they refer to themselves as programmers. If I need a carpenter and it turns out he doesn't know how to use a screwdriver, I wouldn't trust him to build my house/bookshelf/whatever even if he calls himself a carpenter. On no way is this a malfunction of the screwdriver. All kind of screwdrivers are available on the market and anyone can buy them, but the know-how of how to use the screwdriver isn't included in the purchase of the tool. If the screwdriver manufacturer published a proclamation that said "screwdrivers may damage the head of the screws, use our hammer instead if possible", I would certainly doubt any carpenter that claimed this proclamation to be a good advice since I would conclude that he apparently doesn't know how to use a screwdriver. Of course it's always technically possible to use a hammer instead of a screwdriver, but that would cause unwanted side effects that are obvious to skilled carpenters.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownRoger Stoltz wrote:
I suspect that technically there is always a single threaded solution.
Sure. Have a circular queue filled with state machines. Give each state machine an "Execute" method and a message queue. During the life time of your application, iterate through the queue calling "Execute" on each state machine. In turn a state machine processes the messages in its queue taking whatever action is appropriate given its current state. A state machine can communicate with another state machine by sending it a message which the receiving state machine stores in its message queue (and later processes when its "Execute" method is called). If you want to get fancy, you can give some state machines a higher priority than others. The key to getting this approach to simulate multithreading is for each state machine to complete its "Execute" method as quickly as possible. The above approach is not necessarily a realistic solution in many/most situations, but I could see it used in some situations in which threads are not available or you want to minimize the use of threads.
-
logan1337 wrote:
"Because multithreaded programs are complex and difficult to debug, they should be avoided when single-threaded solutions exist."
I think others have touched on the majority of the subjects related to this. I would agree, to a point, simplicity is better. However, I can point out that all solutions has a single-threaded alternative, therefore, to be litteral, you would never use multithreaded. This is why people are so shocked at the idea. I would rephrase it to say, "Multithreaded programs are more difficult to debug, so care and retraining of personell may be required. Ultimately, you should use multithreaded operations to solve performance problems that strongly benefit from multi-threaded operations. If your GUI has not reached a complexity to require multi-threaded operation, say, a scientific calculator (non-programmable), then don't use it. But if your application has serious performance concerns from processing, to multi-function ability, one should not shy away from multi-threaded operations. I do believe programmers should be trained, not just in threading, which is a first step, but in full parallel operations. It is "a little knowledge is a dangerous thing" that keeps multi-threaded programming as the bane to programmers as a whole. We tend to take the small step, thinking if we learn the syntax of threading, everything else will just "happen" for us.... Thus bugs. If we take the full step, and learn parallel programming, lock-free atomic ops, data sharing, etc., we learn the full language of operations to help us in our work. The result of going "all the way" is that we understand where the problems are and avoid them, rather than complaining that multi-threading is the bane of our existance and we want all multi-cores to stop splitting!! Multi-core is here to stay. We just made 4 cores, we're heading for 8. In fact 8 cores is already here in some architectures (just not intel/amd). But 8 is coming on the PC, then 16, then 32. By 32 they "hope" there will be another way of handling things. But I doubt it. Even if we find an alternative to speed up computation cycles that is better than the IC and doesn't suffer from the heat problems, it will still be faster as a multi-core solution also. Multi-core is not going to disappear tomorrow, or the next day. It is here, and it is time we faced that. Learn how to use it, whether it is TPP or TBB, or OpenMP, or a native architecture solution, learn it, learn it ALL, learn
-
logan1337 wrote:
"Because multithreaded programs are complex and difficult to debug, they should be avoided when single-threaded solutions exist."
I think others have touched on the majority of the subjects related to this. I would agree, to a point, simplicity is better. However, I can point out that all solutions has a single-threaded alternative, therefore, to be litteral, you would never use multithreaded. This is why people are so shocked at the idea. I would rephrase it to say, "Multithreaded programs are more difficult to debug, so care and retraining of personell may be required. Ultimately, you should use multithreaded operations to solve performance problems that strongly benefit from multi-threaded operations. If your GUI has not reached a complexity to require multi-threaded operation, say, a scientific calculator (non-programmable), then don't use it. But if your application has serious performance concerns from processing, to multi-function ability, one should not shy away from multi-threaded operations. I do believe programmers should be trained, not just in threading, which is a first step, but in full parallel operations. It is "a little knowledge is a dangerous thing" that keeps multi-threaded programming as the bane to programmers as a whole. We tend to take the small step, thinking if we learn the syntax of threading, everything else will just "happen" for us.... Thus bugs. If we take the full step, and learn parallel programming, lock-free atomic ops, data sharing, etc., we learn the full language of operations to help us in our work. The result of going "all the way" is that we understand where the problems are and avoid them, rather than complaining that multi-threading is the bane of our existance and we want all multi-cores to stop splitting!! Multi-core is here to stay. We just made 4 cores, we're heading for 8. In fact 8 cores is already here in some architectures (just not intel/amd). But 8 is coming on the PC, then 16, then 32. By 32 they "hope" there will be another way of handling things. But I doubt it. Even if we find an alternative to speed up computation cycles that is better than the IC and doesn't suffer from the heat problems, it will still be faster as a multi-core solution also. Multi-core is not going to disappear tomorrow, or the next day. It is here, and it is time we faced that. Learn how to use it, whether it is TPP or TBB, or OpenMP, or a native architecture solution, learn it, learn it ALL, learn
5 for the Yoda quote! :laugh:
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
-
I just realized why some people seem like aholes when posting. There seems to be so many of them. I was beginning to think that coders are mostly aholes. When you are behind a nickname it is easier to say what you think. At the same time, think of this world where this is practiced in real life too. From the language and expressions on this forum we would kill each other off. This is where hypocrisy comes in and saves the day when you politely tell your coworker: "I see your point, but maybe it would be better if...". Thank god for hypocrisy! :D
I'd just say that some postings, while making a valid point, could benefit from somewhat more diplomacy. How's that for being diplomatic?
codewizard
-
Roger Stoltz wrote:
I suspect that technically there is always a single threaded solution.
Sure. Have a circular queue filled with state machines. Give each state machine an "Execute" method and a message queue. During the life time of your application, iterate through the queue calling "Execute" on each state machine. In turn a state machine processes the messages in its queue taking whatever action is appropriate given its current state. A state machine can communicate with another state machine by sending it a message which the receiving state machine stores in its message queue (and later processes when its "Execute" method is called). If you want to get fancy, you can give some state machines a higher priority than others. The key to getting this approach to simulate multithreading is for each state machine to complete its "Execute" method as quickly as possible. The above approach is not necessarily a realistic solution in many/most situations, but I could see it used in some situations in which threads are not available or you want to minimize the use of threads.
:laugh: Yep, that was one of the approaches I had in mind. My point was that it's ridiculous to formulate a condition saying "avoid multithreaded implementations when single threaded solutions exist" since there's always a single threaded solution which is technically possible to implement. The single threaded solution may however cause undesired side effects such as unresponsive UI. Considering the ridiculous form of the advice I assume that it is aimed at hobby programmers that haven't got the basics down yet regarding multithreading. For the record I don't endorse making multithreading "simpler". I think it's far too common in this business that people consider themselves programmers with complete lack of talent and/or basic understanding of software development. My point is not that people are unable to learn, but with some programming languages and/or various software packages they don't have to and that's the problem. A skilled and/or talented professional knows which tool to select to get the job done and one tool in the programmers toolbox is multithreading. This doesn't imply that this particular tool can be utilized for solving all problems. Thus the MS advice cannot be aimed at skilled and/or talented SW professionals.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
:laugh: Yep, that was one of the approaches I had in mind. My point was that it's ridiculous to formulate a condition saying "avoid multithreaded implementations when single threaded solutions exist" since there's always a single threaded solution which is technically possible to implement. The single threaded solution may however cause undesired side effects such as unresponsive UI. Considering the ridiculous form of the advice I assume that it is aimed at hobby programmers that haven't got the basics down yet regarding multithreading. For the record I don't endorse making multithreading "simpler". I think it's far too common in this business that people consider themselves programmers with complete lack of talent and/or basic understanding of software development. My point is not that people are unable to learn, but with some programming languages and/or various software packages they don't have to and that's the problem. A skilled and/or talented professional knows which tool to select to get the job done and one tool in the programmers toolbox is multithreading. This doesn't imply that this particular tool can be utilized for solving all problems. Thus the MS advice cannot be aimed at skilled and/or talented SW professionals.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownRoger Stoltz wrote:
My point was that it's ridiculous to formulate a condition saying "avoid multithreaded implementations when single threaded solutions exist" since there's always a single threaded solution which is technically possible to implement. The single threaded solution may however cause undesired side effects such as unresponsive UI.
Point well taken. :)
Roger Stoltz wrote:
Considering the ridiculous form of the advice I assume that it is aimed at hobby programmers that haven't got the basics down yet regarding multithreading.
I have to admit that when I first read the quote, this didn't occur to me. But after reading your post, it's obvious now. FWIW, I over-snipped your previous post. I read the first line and jumped at the opportunity to describe a use for state machines, something I can rarely resist doing. :)
-
First, yes that is an awful stupid comment from Microsloth. Second, did you read the whole article? The preceeding sentence said "Windows Presentation Foundation (WPF) is designed to save developers from the difficulties of threading. As a result, the majority of WPF developers won't have to write an interface that uses more than one thread. " The very next sentence says "No matter how well architected, however, no UI framework will ever be able to provide a single-threaded solution for every sort of problem." So taken in context it does make some sense. But, hey it is much more fun to take things out of context. As for the VB bashers out there... So what? Are you jealous? Or angry that you spent so much time and money on your education and they didn't? Or is this being proud that you received some sort of "Formal Education"? I didn't and have been in this business for many years and started out with "Microsoft Access" when it was first released and move deeper into programming. Yes, Idiots who use "On error resume next" are idiots. Oddly enough, I have meet quite a few who went to University and other forms of formal education. Do they give you a bad name? I feel that bashers like you give the rest of us programmers a bad name.
-
Roger Stoltz wrote:
I suspect that technically there is always a single threaded solution.
Sure. Have a circular queue filled with state machines. Give each state machine an "Execute" method and a message queue. During the life time of your application, iterate through the queue calling "Execute" on each state machine. In turn a state machine processes the messages in its queue taking whatever action is appropriate given its current state. A state machine can communicate with another state machine by sending it a message which the receiving state machine stores in its message queue (and later processes when its "Execute" method is called). If you want to get fancy, you can give some state machines a higher priority than others. The key to getting this approach to simulate multithreading is for each state machine to complete its "Execute" method as quickly as possible. The above approach is not necessarily a realistic solution in many/most situations, but I could see it used in some situations in which threads are not available or you want to minimize the use of threads.
Leslie Sanford wrote:
Sure. Have a circular queue filled with state machines. Give each state machine an "Execute" method and a message queue. During the life time of your application, iterate through the queue calling "Execute" on each state machine. In turn a state machine processes the messages in its queue taking whatever action is appropriate given its current state. A state machine can communicate with another state machine by sending it a message which the receiving state machine stores in its message queue (and later processes when its "Execute" method is called). If you want to get fancy, you can give some state machines a higher priority than others.
actually, you can use this in a scaleable structure. If execute() is handled on 1-n number of threads, you can have a scaleable architecture quite readily. The question is what you are trying to do with it. If you are trying to solve a difficult and mathematically intensive problem, multi-threading, even in a worker-thread environment, offers significant improvement in speed. But it comes down to the old profiling trick: Don't optimise code you rarely call. Don't multi-thread code that isn't CPU intensive or idle/blocked. In the end it comes down to common sense, and unfortunately common sense is not always very common.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
There's a sentence in the following paragraph of the article you refer to which states: "WPF comes close, but there are still situations where multiple threads improve user interface (UI) responsiveness or application performance." The truth of the matter is as follows: presently there exist dual core processors and not too far in the future there will be processors with even more cores. Single threaded application design does not take the best advantage of these new hardware configurations. It seems the individual at Microsoft that wrote the article is very knowledgeable of WPF and perhaps what is written in the article did not come across as he intended. I helped Jeffrey Richter with the creation of "CLR Via C#." And actually, it was upon my suggestion that he added a very good chapter on thread synchronization. (Which is why it is the last chapter of the book - for those of you into trivia). If anyone is interested in learning about threading concepts then I highly recommend that chapter. In my opinion, using multiple threads versus using the application main thread is a choice a company or developer makes in order to determine how responsive an application's ui is. For example, look at Outlook and you will see that application is unresponsive while performing a good number of its tasks. In contrast, look at a program like inTriever, www.intriever.com, which is multithreaded (I made inTriever but am only mentioning it as an example for the sake of this discussion) and notice the ui remains responsive at all times. If you compare a single core system to a hyperthreaded or multi core pc you will see the added benefit a multi-threaded program like inTriever provides whereby a single threaded application like Outlook does not take full advantage of the extra processing power. Not every application needs a multithreaded design if, for example, the functionality it offers is simple and does not require a lot of processor resources. However, applications seem to be getting more and more complex in order to provide more advanced features. IMHO, multi-threaded application design is a necesary evil in order for the new generation of applications to provide the new functionalities the general public wants.