Thread Deadlock Problem.
in [MFC]
|
Prev: "Problems"
Next: How well can TextOut() handle Unicode?
From: Joseph M. Newcomer on 19 Feb 2010 16:40 See below... On Tue, 16 Feb 2010 01:14:39 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote: > >Joseph M. Newcomer wrote: > > > >>>> There is a mythos about how fast the brain works. The brain > > >>> is actually amazingly slow. > >> > >>> Compared to what? > > > > >> **** >> Oh, say, a 4-function calculator. Go read Lindsay & Norman "Human Information >> Processing", the introductory book to cognitive psychology. >> **** > > >hmmm, you mean the calculator (any computer) is faster at reaching a >1x0 conclusion than a human? **** Not sure what you mean, but if you mean "one multiplied by zero equals zero", of course. A Pentium 4-class machine does this, in floating point, in about 350 picoseconds. That isn't even close to neural propagation delays. ***** > >Well, not really the same analogy, is it? Your calculator or Cray >isn't going to do much good at intelligence and putting together >unrelated consequences. Now I'm thinking Query Dissemination Theory, >i.e, where you no longer calculating but *zooming* to a learned >solution. i.e. like entering 1x0 into your 4-func calculator once and >never have to do it again! In that vain, the calculator is a stupid >device and slower from typing and looking at the LED waiting for an >answer at getting to the answer 0 when you can do with no hands and >your eyes close, "almost" no thinking involved. Now, if you wish to >begin to emulate this behavior in the calculator, then give it a short >circuit for zero and other known conditions that will eliminate flip >flopping bits and not really do any "processing" at all. :) **** The thing that makes the brain interesting is the massive parallelism on information retrieval, and the ability to have insights far beyond anything that mechanical emulation would suggest given the neural delays. But in most cases, we think no faster than we talk. This has been demonstrated many times. But we are *excellent* pattern recognizers. Example: I was once handed, by a researcher, a 1-page FORTRAN program. It was placed face-down on the table, and the back of the assignment described a bug in the program, in the form "The program is expected to produce an answer X, and instead it produces an answer Y". The goal was to measure how long it took to isolate the bug. The program was about 40 lines of code. So they said "Go", hit the stopwatch, and I turned it over. I found the bug in 35 seconds, and was sort of disappointed it had taken so long. It turns out the BEST anyone had done before this was seven minutes! Why? Because I had a debugging pattern in my head already. When I turned the page over, I just scanned the code for the print statement, and worked backwards three statements to the erroneous statement. All other subjects had been undergraduates, who felt they had to start at the top of the program, read it line by line, and understand it before they could fix the bug. I had a completely different pattern, and applied it (at that point, I had been a programmer about 16 years). THIS is the power of the human brain. But, when I was asked to redo it and speak aloud what I was doing, it took about 40 seconds for me to repeat my reasoning aloud, comparable in time to my solution time. At that point, the researchers had never considered that highly-experienced programmers had a different paradigm than beginners. As research proved later, this is true in a variety of human activities; the difference between a professional and an amateur can largely be categorized as the richness of patterns based on experience. We are among the very best pattern-matchers around. And if you look at much of AI research, it is attempting to synthesize powerful pattern recognizers based on experience to enrich that capability. Humans are born with this as part of their "base ROM" code! joe Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 19 Feb 2010 17:29 Joseph M. Newcomer wrote: > [SNIP] > As research proved later, this is true in a variety of human > activities; the difference between a professional and an amateur can largely be > categorized as the richness of patterns based on experience. > > [SNIP] And the high ability to disseminate. Chemical engineers knew this for a long time! We were the original systems and pattern recognition coders! :) -- HLS
From: Joseph M. Newcomer on 20 Feb 2010 00:28 See below... On Tue, 16 Feb 2010 17:09:23 -0500, "Keaven Pineau" <keavenpineau-no-more-spam(a)videotron.ca-no-more-spam> wrote: >After reading your suggestions, I have changed the way I communicate between >the worker thread and the UI. I used message via PostMessage() which solved >almost all my issues. The only thing left was to pay attention and not >calling SuspendThread() several times without calling ResumeThread() each >time because the counter will not be at zero when I will try to stop the >thread and therefore causing a deadlock on my thread handle >WaitForSingleObject() . **** If you call SuspendThread for any reason whatsoever, your design is broken beyond recovery. NEVER, EVER use SuspendThread. And the only place you use ResumeThread is after you create a thread with the CREATE_SUSPENDED flag. You call it exactly once, for the lifetime of the thread. Trust me, you are in very, very, VERY deep trouble if you ever call SuspendThread, you just haven't hit the utlimately fatal set of conditions you will eventually hit. Whatever it takes, you MUST remove that call from your program! **** > >Despite the fact that I found out your way to answer a bit harsh , I will >thank you to point me in a good direction to solve my problem. **** For me, I gave a polite answer. See my previous answer. The code presented is a mess, to put it mildly. joe **** > >Keaven > >"Keaven Pineau" <keavenpineau-no-more-spam(a)videotron.ca-no-more-spam> wrote >in message news:e2v2KMCrKHA.4492(a)TK2MSFTNGP05.phx.gbl... >> Hello all, >> I did a dialog application with an utility class with 2 working threads in >> it that are calling callback functions of the xxxdlg class. >> >> Thead A is my main working thread. This thread his waiting on 2 events : >> 1- Quit Event >> 2- Optional callback call Event >> >> This thread is calling a callback function on every >> WaitForMultipleObjects() timeout, here 5000 ms. >> >> Thread B is an optional thread that can be enable/disable at anytime. >> This thread his waiting only a quit Event and when WaitForSingleObject() >> timeout it is setting the Optional Event of Thread A via SetEvent(). >> Timeout here is 15 000 ms. >> >> Each Thread are calling AfxEndThread(0,FALSE); at the end and the control >> function is waiting on A->m_hThread and/or B->m_hThread before deleting >> their respective object. >> >> Now, if I am not enabling thread B. I can start and end Thread A without >> any issue. If I start both thread A and B and I can also quit them >> without problem if they were both running. Now , If I start both thread A >> and B and stopping thread B and waiting a 10 seconds when I will try to >> stop thread A the WaitForSingleObject() on his handle will deadlock. >> >> I have found out that it is related with the event I am using for telling >> thread A to execute the optional callback. If I simply put the SetEvent() >> in comment, the problem never occurs. >> >> Any idea, why this is happening? >> >> Thank you Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 20 Feb 2010 01:54 child = new mother+father If you think "multiple inheritance" is bad in C++, think about it in the real world! (a) in some cases you don't know which of several classes might be the father (b) you have no idea if the classes compose properly and there is no syntax checker! (c) the methods and variables combine randomly (d) for years, the new class is ill-behaved (e) in later years, memory leaks are common (f) in the first couple years, leaks are also a problem Modern technology has solved some of these, for example (a) DNA tests (b) DNA genetic counseling (c) [still leading-edge research on lower life forms] genetic engineering (d) [no solution, but eliminating ages 0-2 and 13-19 has been suggested] (e) Drugs are now available to help with this (d) Disposable diapers joe On Fri, 19 Feb 2010 17:29:21 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >Joseph M. Newcomer wrote: > > > [SNIP] > >> As research proved later, this is true in a variety of human >> activities; the difference between a professional and an amateur can largely be >> categorized as the richness of patterns based on experience. > > > > > [SNIP] > >And the high ability to disseminate. Chemical engineers knew this for >a long time! We were the original systems and pattern recognition >coders! :) Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 20 Feb 2010 08:36
Except in a bastardization process, no one really cares. :) Joseph M. Newcomer wrote: > child = new mother+father > > If you think "multiple inheritance" is bad in C++, think about it in the real world! > (a) in some cases you don't know which of several classes might be the father > (b) you have no idea if the classes compose properly and there is no syntax > checker! > (c) the methods and variables combine randomly > (d) for years, the new class is ill-behaved > (e) in later years, memory leaks are common > (f) in the first couple years, leaks are also a problem > > Modern technology has solved some of these, for example > (a) DNA tests > (b) DNA genetic counseling > (c) [still leading-edge research on lower life forms] genetic engineering > (d) [no solution, but eliminating ages 0-2 and 13-19 has been suggested] > (e) Drugs are now available to help with this > (d) Disposable diapers > > joe > On Fri, 19 Feb 2010 17:29:21 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote: > >> Joseph M. Newcomer wrote: >> >>> [SNIP] >>> As research proved later, this is true in a variety of human >>> activities; the difference between a professional and an amateur can largely be >>> categorized as the richness of patterns based on experience. >>> [SNIP] >> And the high ability to disseminate. Chemical engineers knew this for >> a long time! We were the original systems and pattern recognition >> coders! :) > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm -- HLS |