> One little glitch remains. The mother needs to know when the daugnter > is ready to accept more work. Either of the following works: > > o The daughter can simply clear the ECB to zeroes and the mother > can use this as an indication that the daughter is ready to be > POSTed. But in some cases, the mother might end up spinning > until the daughter clears the second ECB. So, better:
Nope. It falls prey to the TOCTTOU problem. Moreover, the "normal" content of the ECB after a post is X'40000000', so any scheme that depends on a compare and swap is going to be easily duped and misled by successive (potentially valid) posts on the same ECB in between waking from the first successful post and attempting to clear the ECB. And making either or both sides spin is very counter productive. > o Introduce a second ECB. When the daughter has accepted the > work item or is ready for more work, it clears the first ECB, > POSTs the second, and WAITs on the first. When the mother > needs the daughter's assistance, it WAITs on the second ECB, > clears it, and POSTS the first. If there's a communication > area, neither task should POST until it has completed reading > or updating that communication area; effectively POSTing > transfers ownership of the communication area (and the POSTed > ECB) to the other task. The mother must clear both ECBs before > ATTACH. The daughter must POST the second ECB as part of > initialization after it has been ATTACHed. > > This is the reason that "a pair of ECBs" has been mentioned > earlier in this thread. (I believe I'm "close as in horseshoes" > here.) If you're doing asynchronous request/response processing between two or more tasks you end up having no choice but to introduce an ECB for each "side" of the conversation between any two service tasks. However, that alone is not enough - except in the case where the communication is strictly half duplex. If your application design can guarantee that the lone ECB can only ever be posted serially then "no problem"; but asynchronous applications are rarely that compliant. 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. Did I mention it was a crap mechanism? CC ---------------------------------------------------------------------- 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
