Can extra processing threads help in this case?
in [MFC]
|
From: Joseph M. Newcomer on 29 Mar 2010 14:37 See below... On Mon, 29 Mar 2010 10:58:56 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:4n30r5p0lnqjf7u5tbfodjkjnp9kt05vul(a)4ax.com... >> See below... >> On Thu, 25 Mar 2010 14:32:19 -0500, "Peter Olcott" >> <NoSpam(a)OCR4Screen.com> wrote: >> >>> >>>"Pete Delgado" <Peter.Delgado(a)NoSpam.com> wrote in message >>>news:ORrRkLEzKHA.928(a)TK2MSFTNGP05.phx.gbl... >>>> >>>> >>>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >>>> news:EqmdnZkWypVi7DbWnZ2dnUVZ_rednZ2d(a)giganews.com... >>>>> (By fault tolerance I mean yank the power plug from the >>>>> wall and when the machine is re-started it (as much as >>>>> possible) picks up right where it left off) >>>> >>>> ...take a look at transactional NTFS. >>>> >>>> http://msdn.microsoft.com/en-us/library/aa365738(VS.85).aspx >>>> >>>> -Pete >>>> >>> >>>Which I bet requires some sort of persistent storage, yup >>>it >>>does. >>>How could I have very fast inter process communication >>>that >>>is also fault tolerant, or are these two mutually >>>exclusive? >> **** >> Why do you suddenly add "fault tolerance", then add "fast >> interprocess communication that >> is also fault tolerant"? I think you are totally and >> utterly clueless here. You do not >> understand ANY of the concepts involved. >> >> If you have fault tolerance, why does it have to be in the >> IPC mechanism? In fact, it >> would probably be a Really Bad Idea to try that. > >Although it may be temporary ignorance on my part that >suggested such a thing, I was thinking that it might be >simpler to do it this way because every client request will >be associated with a financial transaction. Each financial >transaction depends upon its corresponding client request >and each client request depends upon its corresponding >financial transaction. With such mutual dependency it only >seemed natural for the underlying representation to be >singular. **** There are several possible approaches here, with different tradeoffs. (a) get PayPal acknowledgement before starting the transaction (b) Because the amount is so small, extend credit, and do the PayPal processing "offline" out of the main processsing thread; in fact, don't even request the PayPal debiting until the transaction has completed, and if it is refused, put the PayPal processing FIRST for their next request (thus penalizing those who have had a refused transaction); you might lost a dime here and there, but you have high performance for other than those who aren't cleared. (c) if the transaction fails, and you have already debited the account, have a background process credit the account for the failed transaction. You are confusing IPC with robustness mechanism. IPC is a pure and simply a transport mechanism; anything about robustness has to be implemented external to the IPC. joe > >> I guess I'm biased again, having built >> several fault-tolerant systems. >> joe >> **** >>> >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm > 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 29 Mar 2010 14:57 See below... On Mon, 29 Mar 2010 09:27:15 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:ccqvq5tdav2raahjk72sgiab0a4ttbrjjh(a)4ax.com... >> See below... >> On Thu, 25 Mar 2010 09:18:32 -0500, "Peter Olcott" >> <NoSpam(a)OCR4Screen.com> wrote: >> >>> >>>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >>>message >>>news:OOcyQDBzKHA.5288(a)TK2MSFTNGP05.phx.gbl... >>>> Peter Olcott wrote: >>>> >>>>> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>> >>>>>> A multithreaded FIFO queue would make more sense; less >>>>>> chance of priority inversion >>>>>> effects. An I/O Completion Port makes a wonderful >>>>>> multithreaded FIFO queue with >>>>>> practically no effort! >>>>>> joe >>>>> >>>>> How ? >>>> >>>> Well, there will be programming effort with IOCP, his >>>> main >>>> point is that you don't understand enough programming >>>> ideas under Windows that you behaving here like a new >>>> kid >>>> who just discovered the toaster oven and you don't want >>>> follow others cooks or read a cook book in the many ways >>>> to use the toaster oven. >>>> >>>> Look, your SOCKET is a FIFO. Its inherent. So when >>>> connects come in, they are queued, designed for >>>> multi-threaded worker pool concepts to handle the >>>> incoming >>>> request. >>>> >>>> So what you do? >>>> >>>> You don't use threads, and you slow it down by adding >>>> ANOTHER FIFO queue to run the OCR per request one at a >>>> time. >>>> >>>> But now you think, I got a MONSTER machine. Its easier >>>> for >>>> me to use create a EXE with MONGOOSE+OCR and run it 4 >>>> times, assuming it will be 1 EXE per multi-core >>>> processor. >>> >>>No you have this wrong. For proving that multiple threads >>>would work multiple processes sufficed. In practice I will >>>use multiple threads. >> **** >> No, it doesn't. And if it is not obvious to you why this >> is true, you are being more >> obtuse than any human being has the right to be. Or, as >> I've said before, denser than >> depleted uranium. Perhaps you do not understand the >> difference between thread scheduling >> within a process and scheduling thread when the process >> context changes. Perhaps you do >> not understand how computers work, and that's why you are >> asking questions, and those of >> us who KNOW what is going are desperately trying to >> explain to you that your experiment is >> so deeply flawed as to be irrelevant, and WHAT PART OF >> THAT DO YOU FAIL TO UNDERSTAND? You >> are comparing incomparable experiments, and your >> resistance to running the correct >> experiment is truly impressive for someone who has already >> proven himself to be totally >> clueless. I even tried to explain that the experiments >> are incomparable, but gee, that's >> based on my understanding of the operating system and the >> x86 chip, and what the context >> swap code is known to do when swapping process contexts >> (do you know what the implications >> of "TLB Flush" are on your performance?) Maybe my >> tendency to read documentation biases >> me, and you have no such biases. >> joe > >I know the difference between threads and a process and see >no reason why threads would not work if processes do work >the converse not necessarily being true. **** Memory interference patterns will be completely different in a multithreaded single process. **** > >What difference is there between threads and processes that >is the basis for even the possibility that threads may not >work whereas processes do work? **** It is sad you have to ask this question. See above comment. There are substantial changes in how the memory system is handled in inter-process context switching than intra-process context switching. And the consequences are quite different. So MAYBE you will get comparble performance, MAYBE it will be a lot better, and MAYBE it will not be as good. I have no idea. But *I* would have run the experiment so I would KNOW, and not just be guessing based on the wishful-thinking approach baed on one irrelevant experiment. **** >Please do not site a laundry list of the differences between >threads and processes, please only cite at least one >difference between threads and processes along with >reasoning to explain why they might not be used whereas >threads worked correctly. **** See above. **** > >Here are two crucial assumptions why I think that threads >must work if processes do work: >(1) Threads can share memory with each other with most >likely less overhead than processes. **** And higher potential interference. You don't really know. **** >(2) Threads can be scheduled on multiple processor cores, >just like processes. **** See previous comment about memory interferene patterns. The point is, I DON'T KNOW, but I don't believe in extrapolating from unrelated experiments. GET THE &%$#ING DATA! **** > >> >> You are going to have to come up with a better proposal >> than one that uses the words "some >> sort" in it. >> joe > >All that I was saying is that my mind is still open to >alternatives than the ones that I originally suggested. **** It sounded to me like you have not been open to ANY alternatives we have suggested, and you don't write specifications using phrases like "some sort" in them. You write VERY specific requirements, and from those requirements, generate VERY specific implementation strategies. Then, those strategies are reviewed and might be rejected or accepted, based on both technical feasibility and whether or not they satisfy the requirements. And you have demonstrated that technical feasibility is not one of your strongest points. First, though, you need a very precise requirement, one which incorporates everything that is essential and eliminates anything that is now "moot". So we have something to work with that is actually self-consistent, and not morphing on every restatement. Then a detailed implementation specification which tells exactly how you plan to meet that requirement. joe **** > >> >>> >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm > 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 29 Mar 2010 15:13 On Sun, 28 Mar 2010 23:23:09 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:ehcvq55h4l9lrobkpabb2m31ve22nvffd4(a)4ax.com... >>I had forgotten that! And I DID tell him about >>VirtualLock! >> >> Denser than depleted uranium. >> >> What is amazing is his persistence in using technically >> incorrect terminology even after >> it has been carefully explained to him what is going on. >> For example, a desire to >> allocate contiguous physical memory should have been the >> first clue that he had no idea >> what virtual memory was. And his persistence in equating >> virtual memory (which, at its > >If all that other stuff that is going on under the covers is >sufficiently analogous to the simpler case, then it is a >communication error to specify these extraneous and >essentially irrelevant details. These extra details impede >the communication process. *** ANd you accuse ME of having communication problems! But you have serious communication problems in that once you are told you are using the technical language incorrectly, you PERSIST in using it incorrectly, thus impeding any form of effective communication. It is NOT "analogous". You asked a VERY SPECIFIC and carefully-worded question, and were told that this was not possible. At which point you began insisting that it HAD to work as you described. These details are NOT "irrelevant" but in fact change the nature of the problem considerably. A fact which we keep trying to explain to you! *** > >In other words the simpler less exactly precise terms are >more correct (within the goal of effective communication) >than the complex precisely correct terms because the >precisely correct terms impede the clarity and conciseness >of communication. **** But the precisely correct terms described what is REALLY going on and the slovenly use of terms impedes the communication because you are, for example, asking for the impossible. If you insist on asking for something that is impossible, you aren't going to get it, no matter how much you want to. And if you insist on the impossible, you demonstrate that you are clueless, particularly after it has been explained to you that you have asked for the impossible.If you say "I must have X" and someone says "that is never going to happen" then you have to accept that you are not going to get "X" and stop insisting that you must have "X". Those of us who make their livings satisfying the needs of customers have, as part of our responsibility, making sure that customer doesn't have unrealistic expectations, and therefore, when we fail to deliver "X" means they will say "I wanted "X", you did not not give me "X", and therefore I am not going to pay you". Been there, done that, thirty years ago, and I don't make the same mistake twice. Intead, I simply say "You are never going to get "X" because that is not how the system works. Now here's what you ARE going to get, that meets your requirements..." Which is why a coherent set of requirements is mandatory (a friend of mine has an interesting approach to pricing. He asks for the requirements document first. If it is well-written, his rate is $N/hr. If it is badly written, or nonexistent, his rate is $1.5*N/hr. He is very upfront about this. Based on your morphing spec, I'd suspect he'd charge $k*N/hr, for k some multiple >= 2, if he had to implement something for you. 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 29 Mar 2010 15:37 Joseph M. Newcomer wrote: >> Although it may be temporary ignorance on my part that >> suggested such a thing, I was thinking that it might be >> simpler to do it this way because every client request will >> be associated with a financial transaction. Each financial >> transaction depends upon its corresponding client request >> and each client request depends upon its corresponding >> financial transaction. With such mutual dependency it only >> seemed natural for the underlying representation to be >> singular. > **** > There are several possible approaches here, with different tradeoffs. > (a) get PayPal acknowledgement before starting the transaction > (b) Because the amount is so small, extend credit, and do the PayPal processing "offline" > out of the main processsing thread; in fact, don't even request the PayPal debiting until > the transaction has completed, and if it is refused, put the PayPal processing FIRST for > their next request (thus penalizing those who have had a refused transaction); you might > lost a dime here and there, but you have high performance for other than those who aren't > cleared. > (c) if the transaction fails, and you have already debited the account, have a background > process credit the account for the failed transaction. > > You are confusing IPC with robustness mechanism. IPC is a pure and simply a transport > mechanism; anything about robustness has to be implemented external to the IPC. > joe Joe, why is his application any different or special than any other client/server framework? He stated: 100 ms RTPT (Response Time per Transaction). That is a 1 thread/process rate. That means within 1 sec, 1 thread can handle 10 transactions per second. Since he also stated: 100 TPS (Transactions per Sec) That means he will need at least 10 threads in his worker pool - period to handle the 100 TPS at 100 ms RTPT. His HTTP posted input REQUEST data will have at a minimum: - HTTP or COOKIE based authentication data, UserAuthData: - MIME based form fields meta data information, UserMetaData - MIME based form upload file data, UserFileData So when a HTTP POST arrives, he needs a "TRequestMetaData" structure with the above plus session related state information. He can start with a enum state point type: enum TRequestState { rsNone = 0, // just to make it understood rsPosted, rsProcessing, rsProcessingComplete, rsSendingResult, rsSendingComplete, rsSuccess }; Altogether, TRequestMetaData structure will contain: struct TRequestMetaData { TUserAuthdata UserAuthdata; TUserMetaData UserMetaData; TUserFileData UserFileData; TUserRespData UserRespData; FILETIME PostTime; FILETIME ProcessTime; FILETIME CompleteTime; TRequestState RequestState }; As long as he keeps this fixed typedef structure, he won't have to worry about class serialization and OLE/VARIANT. However, he can use a CRecordSet with a data exchange handler for an ODBC interface. Either way, the fundamental state machine needs to be established. TRequestMetaData needs to immediately flushed to disk using whatever storage method he wishes to use at each update point: 1 - Request.Add() Initialize new TRequestMetaData record set RequestState = rsPosted set some HASH for the HTTP data request RESTART CHECK - Lookup by HASH to see if request already exist. Go to Proper state accordindly. For new, Append to data file/base Get new row index 2 - Request.StartProcessing() set RequestState = rsProcessing set initialize other processing information Update Record at index location call the DFA/OCR processor (in threaded fashion) wait for completion, thread efficient BLOCKED set RequestState = rsProcessingComplete set other processing complete information Update Record at index location 3 - Request.SendResult Prepare HTTP response set RequestState = rsSendingResult set UserReponseData = HTTP response Update Record at index location Send HTTP result, it is blocked, the only reason for failure of the user disappeared set RequestState = rsSendingComplete set other sending complete information Update Record at index location 4 - Request.Complete() set RequestState = rsComplete set other processing complete information Update Record at index location The above is the basic idea. Of course there are parts that could be folded or reduced or done better. But as Peter D. told Peter O, now he doesn't have to worry about much about faults at any of the above states. Each request state will be known and he can restart or rehandle accordingly. And as you and I told him, he has to negate his idea about no pages, no caching, not because thats bad - its insignificant. Anyway, the only thing really different from any other common application framework like this, is state #2 and the plug and play DFA/OCR processor. Just consider the odds are good the BUGS and FAULTS will be at this point. :) -- HLS
From: Joseph M. Newcomer on 29 Mar 2010 16:20
See below... On Sun, 28 Mar 2010 23:03:42 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:43avq55lpbt1dosbpbd5ie1p4nbvbetksa(a)4ax.com... >> See below... >> On Sat, 27 Mar 2010 22:35:57 -0500, "Peter Olcott" >> <NoSpam(a)OCR4Screen.com> wrote: >> >>>I am not a myriads upon myriads of possibly useful details >>>guy like you are, I am a boil it down to its essence and >>>address everything on the basis of its essence kind of >>>guy. >> **** >> And my point is that your interpretation of the "essensce" >> is completely wrong; in fact, >> you have, to use your boiling analogy, merely achieved a >> thick paste, and you have not yet >> discovered the essense. But you believe that your thick >> paste IS the essence. You >> believe that paging is an essential part of the virtual >> memory model. > >>But you can run >> with virtual memory WITHOUT paging being a part of it, > >How is that not like running an automobile's engine without >any form of fuel? **** Because you are being dense and stupid. For example, a better analogy would be running an automobile engine without transferring the power to the wheels. Running the engine is a valid act; whether or not that power is transferred to something that generates motion is a second-order effect. **** >Please try to be very concise. **** Concise: you are stupid. Slightly longer: virtual memory is a system that maps virtual addresses to physical addresses (which I have said several times, and I know of no reason you would ignore this other than being stupid). Even longer: one of the possible mappings is etended to include the value "not in memory". which induces paging. But if there are no page faults, virtual memory is still running (which Hector and I both told you, and which Hector pointed you at a Mark Russinovich article, in which he explicitly stated that virtual memory is ALWAYS running). Realy concise: CR0<0>==1. **** > >> and paging is an add-on that every >> virtual memory system has used since the ATLAS computer in >> 1961, because main memory has >> ALWAYS been the expensive bottleneck and therefore is >> always oversubscribed. But > >> you lost >> the notion that virtual memory provides private address >> spaces to processes > >How can this work without paging? **** How stupid do you have to be to keep ignoring what I have explained in detail time after time? Don't accuse us of simply doing "refute, refute, refute" when you seem to suffer from the same problem! And don't tell me I didn't tell you where to look! I gave you a citation to the actual Intel manual, to chapter and pages You DID go read that, didn't you? If you didn't read it, why are you telling me that my definition of virtual memory is flawed? I used my first VM system in 1967 (43 years ago) and have been using it on nearly every machine I've worked on since, and you are telling me that you are an expert on what it is? When you make such obviously erroneous statements, and ask the same question over and over, even after it has been explained to you why you are wrong? Get a life! Either you LEARN about this from the actual sources (the Intel manuals) or you shut up and accept the explanations the experts give you, because at the moment, you lack every conceivable basis for making your ridiculous statments. And you can't even produce a decent analogy! **** >Whichever one can work without the other is the more >essential one. **** What part of "virtual memory is a system that maps virtual addresses to physical addresses" did you fail to comprehend? And what part of "Virtual memory systems use paging as a mechanism to allow the oversubscription to physical memory" did you fail to comprehend? Virtual memory will run WITHOUT paging, but then you are not permitted to have the set of running processes oversubscribe phyiscal memory. You already told us that your process runs without paging, and that is evidence that virtual memory operates without paging! So given your effort to prove paging is not required for virtual memory, why is you insist now that it is necessary for virtual memory? Of course, if you errneously persist in defining the term "virtual memory" with "memory that requires paging", then your axiom is failed, and all conclusions you reach from the failed axiom are erroneous. You are flat-out WRONG about what defines "virtual memory" and it is time you accept this and work with the REAL definition of what "virtual memory" actually is, not your fantasy definition. joe **** > > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |