> > (I did say "clear the ECB" before POSTing the other task, didn't I?) > > That's "should", not "must". And why not? It can't really matter, > > because even if the code is the minimal: > > > > WAIT > > L R1,ECB Preserve condition code > > XC ECB,ECB Clear ECB for next cycle > > > > ... there's still the possibility that the waiter will lose control > > and some other task be dispatched between the WAIT and the XC. Is > > there any hazard in another task's (or the same task's) being able > > to observe the ECB with the POST bit set? If the concern is that > > the path from WAIT to XC may be so long that the waiter misses a POST > > by the other task during that interval, the design is wrong. The > > coder mustn't (not "shouldn't") count on winning that race. > > These days it's a non-issue; instead of XC use CS.
Nope! After a normal post the compare value is going to be X'40000000' and the swap value is going to be 0. If another post intervenes and stores another X'40000000' in place of the first, then the compare is going to succeed and you'll miss a valid post. There's no way out of this dilemma. In anything but the most trivial case you need more application logic combined with a queuing mechanism so that missing a post is harmless. 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
