On Tue, 22 Jan 2008 10:51:29 -0800, Edward Jaffe wrote: >Craddock, Chris wrote: >> More typically you also need to develop a robust queuing mechanism for >> passing work requests and responses between requesters and servers. That >> is because, if you look dispassionately at the ECB as an interface, >> there is no way to avoid the potential of missing an intervening post >> when you clear the ECB. >> > >Exactly! I'm glad somebody *finally* interjected this into the discussion! > >The ECB interface is too often -- but should never be -- used as or >confused with an asynchronous queuing mechanism. Otherwise, requests >_will_ be lost! > >Rather, to request that a service task perform some function, one should >put the request on a queue and then POST the ECB on which the service >task WAITs for work. (Note: In a design involving multiple requesters, >many such requests might be queued before the service task has a chance >to wake up.) The service task wakes up, clears the ECB, and then pulls >work requests off the queue, and processes them, until the queue is >empty. At that point, the service task WAITs on the ECB again. > And you still need a design that covers the case in which a POST occurs between "wakes up" and "clears the ECB". CS may cover this, but it's not obvious how. Perhaps if each POSTer supplies a unique condition code? And a design that serializes queue insertion among multiple requesters.
What CC envisions is something like semaphores, which support multiple concurrent queue fillers and multiple concurrent queue emptiers. You and he are making clear the deficiencies of WAIT/POST. It is what it is. VAX had instructions for atomic list element addition and deletion. Is this what PLO is for? I've used POSIX pipes to implement a sort of semaphore. A circular list of request blocks, using CS to update the insertion and extraction pointers? Hmmm. Each block needs 3 states: empty, full, and busy. (All assuming that the request block is larger than any operand of CS.) But remember the OP's naivete (no slight; it's a good question). surely we're providing TMI. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
