Microsoft on Multithreading
-
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.
-
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.
rourke11 wrote:
But, hey it is much more fun to take things out of context.
:laugh: It certainly does make it more controversial! ;) I realize the point of the article, but I still think there's no excuse for such a silly statement, especially by such an important influence as Microsoft, ESPECIALLY in this day and age where multicore computing is becoming so important.
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
-
For the record, people, the quote had nothing to do with VB; I don't know where all of that came from. :doh:
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
-
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.
AKAJamie wrote:
presently there exist dual core processors and not too far in the future there will be processors with even more cores.
actually, that should read.... presently there exists quad core processors for the PC and not too far in the future there will be processors with even more cores. Cell architecture already goes up to 8 cores if I recall, GPU systems run 128 streaming processors, other specialty boards other numbers. But the point is, right here, right now, you can run out and buy 8 cores in dual processors for a PC architecture, or 4 cores for a single processor. You don't have to wait long either, they aren't special order or anything like that. They are in stock in many places and can probably be to your house in a week to operate on. In less than two years we will be 8 cores, with dual processors to 16 cores at your desk. You can special order a quad processor board, that may take an extra couple of weeks because they are low stock, but you can have 16 cores at your desk before Christmas if you really wanted to and had the money to do so. It's only going to go up from there!
AKAJamie wrote:
Single threaded application design does not take the best advantage of these new hardware configurations.
well said. Those 4 cores available now are wasted, but it is up to us as programmers to get on the ball and fix it. :-D
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
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'?
Well said Gonzo. It seems that many programmers forgot why BASIC even came to be (see http://en.wikipedia.org/wiki/BASIC[^] for a history lesson.) Remember that BASIC and susequent incarnations were designed to make programming more accessible to the masses. As with all things, the larger the population, the greater the likelyhood that you will have abusers of the system. Considering that VB was designed for those who could not or would not grasp the intricacies of C based languages, I think that it has been an incredible success. There are now many programmers who started with a VB or BASIC derivitive who would not have been a programmer otherwise. More Programmers = More Ideas = More Innovation The other aspect of VB that separates it from C based languages is the speed of development. Non-critical utility applications and one off projects can be written quickly by Junior or Mid-level programmers, thus freeing the Senior developers and allowing them to work on the mission critical and performance critical applications (which is where they should be focusing their energies anyway.) Finally with the advent of .NET and the CLR, the whole VB bashing is rendered moot. Whatever the language, be it VB or C#, it is all compiled into IL anyway. There are very few things that a C# developer can do that a VB.NET developer can not. Criticizing a developer for choosing the VB.NET toolset is just blind hippocracy. I would rather have someone develop in a language they they feel comfortable with than enforce any prejudice. In the end, the really good programmers can pick up any language, logic is logic.
-
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...
-
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...
Allow me to disagree :) Recently I've been attending a M$ seminar on migrating from VS6 to .NET What the (M$) guy was half-openly saying is that basically VB was a mistake and we should get rid of VB apps ASAP. The main reasons for that is the loose types VB accepts. You know, using DLLs written in VB from a C++ app or viceversa, when your int is ASSUMED unsigned instead of being signed or the other way round. M$ is offering some nice tools to help the aforementioned migration and they really work for C++ but the VB code has to be fixed by hand since there are too many implicit or run-time typecasts.
-
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 just have to say, as a non-professional programmer, that I'm actually really surprised at how many programs are not multi-threaded and how it seems like in the last year that companies have been scrambling to get apps. mutli-threaded. Sure, threading shouldn't be done if not necessary, but there are a good number of applications that would benefit from good multi-threading, and it's really annoying when an application won't operate properly or well because someone chose to do everything on one thread.
-
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
But lock your queue.
This statement was never false.
-
:) Funnily enough, most of his code followed the same pattern
On Error Resume Next.WPF - Imagineers Wanted Follow your nose using DoubleAnimationUsingPath