On Tue, 22 Jan 2008 11:49:34 -0800, Edward Jaffe wrote: >> >>> 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". > >The situation you describe is already covered by the above, tried and >true, technique. Requests are queued *before* the ECB is POSTed. The ECB >is cleared *before* the queue is processed. Any request arriving just >before the ECB is cleared will be handled. Any request arriving just >after the ECB is cleared will result in the ECB being already-POSTed the >next time the TCB WAITs. (Note: it's entirely possible to observe an >already-POSTed ECB and an empty queue prior to the WAIT.) > Aha! At last I see. That answers my question to Peter R. But I was envisioning a technique in which only one task at a time updates the queue, handing it back and forth with two ECBs. Now there's still need to manage concurrent accesses to the queue. I suppose CS can be used for that purpose.
Whenever the queue is empty, the queue emptier WAITs. But if the queue is storage constrained, it can fill up. What does the queue filler do then? Thanks, 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
