Microsoft on Multithreading
-
depends on you're definition of an hobbyist, been working commercial wise for 26 years now. but he who am i. the problem is that I've had to work with to many coworkers that make judgement on stuff without really knowing what there judging on. assumption is the mother of all fuck-ups.
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
-
marcotje wrote:
coworkers that make judgement on stuff without really knowing what there judging on
In the VB area, people get into computing without any formal training hence you get this situation which you are describing. Yes I remember walking into a airport with 10+ comms experience and meeting a guy who had 6 months VB user experience to tell me I had to use his sample (copied from a book using the ActiveX comms control) program base I my program mission critical comms software on. Needless to say I blew him out of the water.
WPF - Imagineers Wanted Follow your nose using DoubleAnimationUsingPath
norm .net wrote:
his sample (copied from a book using the ActiveX comms control) program base I my program mission critical comms software on.
Didn't you like it? It took me ages to write that, and it was touch and go until I discovered that you could write
On Error Resume Nextin Visual basic to make the crashes go away."On one of my cards it said I had to find temperatures lower than -8. The numbers I uncovered were -6 and -7 so I thought I had won, and so did the woman in the shop. But when she scanned the card the machine said I hadn't. "I phoned Camelot and they fobbed me off with some story that -6 is higher - not lower - than -8 but I'm not having it." -Tina Farrell, a 23 year old thicky from Levenshulme, Manchester.
-
norm .net wrote:
his sample (copied from a book using the ActiveX comms control) program base I my program mission critical comms software on.
Didn't you like it? It took me ages to write that, and it was touch and go until I discovered that you could write
On Error Resume Nextin Visual basic to make the crashes go away."On one of my cards it said I had to find temperatures lower than -8. The numbers I uncovered were -6 and -7 so I thought I had won, and so did the woman in the shop. But when she scanned the card the machine said I hadn't. "I phoned Camelot and they fobbed me off with some story that -6 is higher - not lower - than -8 but I'm not having it." -Tina Farrell, a 23 year old thicky from Levenshulme, Manchester.
-
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 !
-
-
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
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'?
-
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:
-
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