Microsoft on Multithreading
-
Surprised? You shouldn't be. Microsoft exists to serve VB programmers. And for the record, i don't mean programmers who use VB - i mean folks that, were it not for the *ahem* ultra-forgiving-rely-on-3rd-party-components-for-anything-even-mildly-difficult existence of VB and kin, would not be able to call themselves programmers. That's why 99% of applications out there will hang their UIs while doing any sort of computation, even though we've been using a threading-friendly platform for well over a decade now. That's why when, upon encountering a grid control in an application, it's a coin flip as to whether or not it will support even the most basic operations such as sorting and keyboard navigation. Of course you should avoid multithreaded solutions when you don't need them. And you should avoid using a scalpel to trim your finger nails. You also should avoid stating the obvious except when speaking to VB programmers and the mentally-handicapped. :rolleyes: ;)
----
...the wind blows over it and it is gone, and its place remembers it no more...
-
They probably mean to not use multiple threads in every single situation. The quote that you have taken is followed by "No matter how well architected, however, no UI framework will ever be able to provide a single-threaded solution for every sort of problem. WPF comes close, but there are still situations where multiple threads improve user interface (UI) responsiveness or application performance."
-
They probably mean to not use multiple threads in every single situation. The quote that you have taken is followed by "No matter how well architected, however, no UI framework will ever be able to provide a single-threaded solution for every sort of problem. WPF comes close, but there are still situations where multiple threads improve user interface (UI) responsiveness or application performance."
Even so, the sentence seems so absurd to me that I found myself baffled that it would be written at all, regardless of whatever "however" followed it. The solution to multithreading being complicated, IMO, is to make multithreading easier, not shying away from it entirely!
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
-
I take that as, "If you don't have to write multithreaded programs, don't." That's sound advice.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: No, Not I - A poem by Holocaust escapee, chief rabbi, and Messiah-follower Daniel Zion (audio) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
They probably mean to not use multiple threads in every single situation. The quote that you have taken is followed by "No matter how well architected, however, no UI framework will ever be able to provide a single-threaded solution for every sort of problem. WPF comes close, but there are still situations where multiple threads improve user interface (UI) responsiveness or application performance."
Mitch F. wrote:
WPF comes close,
Amusing, since WPF is in fact multi-threaded :) Check out the rendering architecture. Grrr, this got hooked to the wrong reply, I meant to the respond to the one above you.
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
-
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
-
Surprised? You shouldn't be. Microsoft exists to serve VB programmers. And for the record, i don't mean programmers who use VB - i mean folks that, were it not for the *ahem* ultra-forgiving-rely-on-3rd-party-components-for-anything-even-mildly-difficult existence of VB and kin, would not be able to call themselves programmers. That's why 99% of applications out there will hang their UIs while doing any sort of computation, even though we've been using a threading-friendly platform for well over a decade now. That's why when, upon encountering a grid control in an application, it's a coin flip as to whether or not it will support even the most basic operations such as sorting and keyboard navigation. Of course you should avoid multithreaded solutions when you don't need them. And you should avoid using a scalpel to trim your finger nails. You also should avoid stating the obvious except when speaking to VB programmers and the mentally-handicapped. :rolleyes: ;)
----
...the wind blows over it and it is gone, and its place remembers it no more...
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
-
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
marcotje wrote:
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.
Write me a spreadsheet application from scratch using NO 3rd Party controls. I'll await your simplied version of it.
WPF - Imagineers Wanted Follow your nose using DoubleAnimationUsingPath
-
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.
-
marcotje wrote:
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.
Write me a spreadsheet application from scratch using NO 3rd Party controls. I'll await your simplied version of it.
WPF - Imagineers Wanted Follow your nose using DoubleAnimationUsingPath
hahhahaah, just as i said, as simple as need be, don't write a hole framework to display a button with a gradient in it. i'll send an ascii representation of my spreadsheet application ;) |__1__|__2__|__3__| here are the cells ;) haven't you been in a project where base functionality requirements are simple but the implementation of it has completely gone of scope coz the senior was sooo happy with all is generic code libs and framework modules.
-
I take that as, "If you don't have to write multithreaded programs, don't." That's sound advice.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: No, Not I - A poem by Holocaust escapee, chief rabbi, and Messiah-follower Daniel Zion (audio) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
hahhahaah, just as i said, as simple as need be, don't write a hole framework to display a button with a gradient in it. i'll send an ascii representation of my spreadsheet application ;) |__1__|__2__|__3__| here are the cells ;) haven't you been in a project where base functionality requirements are simple but the implementation of it has completely gone of scope coz the senior was sooo happy with all is generic code libs and framework modules.
I've worked on a team which developed a spreadsheet similar to Excel, soound like you're a typical hobbyist programming plodding along with simple not to over complicated programs like data entry screens.
WPF - Imagineers Wanted Follow your nose using DoubleAnimationUsingPath
-
-
Even so, the sentence seems so absurd to me that I found myself baffled that it would be written at all, regardless of whatever "however" followed it. The solution to multithreading being complicated, IMO, is to make multithreading easier, not shying away from it entirely!
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
Some problems are inherently complicated - if not strictly bounded, concurrency is one of those. If you can bound your concurrency to 'the set of concurrent processes that do not share state' (e.g. like Erlang does), then concurrency is a lot easier. However, multiple threads with shared state and multiple locks? That's going to have defectsw you never even realised could happen.
-
Surprised? You shouldn't be. Microsoft exists to serve VB programmers. And for the record, i don't mean programmers who use VB - i mean folks that, were it not for the *ahem* ultra-forgiving-rely-on-3rd-party-components-for-anything-even-mildly-difficult existence of VB and kin, would not be able to call themselves programmers. That's why 99% of applications out there will hang their UIs while doing any sort of computation, even though we've been using a threading-friendly platform for well over a decade now. That's why when, upon encountering a grid control in an application, it's a coin flip as to whether or not it will support even the most basic operations such as sorting and keyboard navigation. Of course you should avoid multithreaded solutions when you don't need them. And you should avoid using a scalpel to trim your finger nails. You also should avoid stating the obvious except when speaking to VB programmers and the mentally-handicapped. :rolleyes: ;)
----
...the wind blows over it and it is gone, and its place remembers it no more...
-
A poor quote; perhaps should have been 'Keep it simple, stupid' and not directed at threading. I don't see this as an attack on non-VBers and I don't get the constant sniping at VBers, either. It's just another tool: get over it.
-
I've worked on a team which developed a spreadsheet similar to Excel, soound like you're a typical hobbyist programming plodding along with simple not to over complicated programs like data entry screens.
WPF - Imagineers Wanted Follow your nose using DoubleAnimationUsingPath
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.
-
A poor quote; perhaps should have been 'Keep it simple, stupid' and not directed at threading. I don't see this as an attack on non-VBers and I don't get the constant sniping at VBers, either. It's just another tool: get over it.
digital man wrote:
A poor quote; perhaps should have been 'Keep it simple, stupid' and not directed at threading. I don't see this as an attack on non-VBers and I don't get the constant sniping at VBers, either. It's just another tool: get over it.
Thats correct VB is a tool while the others are Programming Languages ;P
codito ergo sum
-
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!" - unknown -
digital man wrote:
A poor quote; perhaps should have been 'Keep it simple, stupid' and not directed at threading. I don't see this as an attack on non-VBers and I don't get the constant sniping at VBers, either. It's just another tool: get over it.
Thats correct VB is a tool while the others are Programming Languages ;P
codito ergo sum
What's really sad is you probably believe that.