> I don't understand the reams of discussion about how to handle multiple > threads working on a single ECB, or even a single thread spuriously > posting an ECB. It isn't what it was designed for.
Given it was the only mechanism provided, by definition it was intended for all synchronization purposes that were conceived by its designers. And since its use in practice is far wider than the designers had in mind, it suffers a bunch of side-effects and unintended consequences. Stuff happens with a 40 year old OS! > To me, saying that ECB is a poor design is like saying a bicycle is poor > design because you can't use it to reasonably travel the 80 mile round > trip to work and back. No. I'm saying the ECB is a numbskull design, because even a five year old can pick a bicycle out of any lineup, but not even an expert can reliably pick an ECB unless it is actually being waited on. C'mon seriously. Not even a freakin eye catcher? Even in the mid '60s that was just plain dumb design. > Just because you can't use it for a purpose you *want* > to use it for doesn't mean it's poorly designed. Use it for the purpose it > *was* designed for. I -HAVE- been using those services in heavily multi-tasked, multi-address space system code for longer than I care to remember. And in that time I have seen an amazing array of who'da thunkit gotchas with wait/post. I think I'm entitled to a strong opinion on the basis of experience at least :-) Now arguably in the most narrow sense, all of those "quirks" were due to programming errors or bad assumptions on the part of the application developers. But since wait/post is the only tool that came in the tool box and there were no safety instructions in the doc it is no wonder more than a few folks got their eyes poked out, or gave up because they couldn't get their multitasking application to go. OS/360 and its offspring are like that. It's probably the most user-vicious system around, but we've all gotten used to its quirks - kinda like learning to run with scissors. Familiarity with a bad design and the ability to code around a bad design or to effectively use the artifacts of a bad design do not alter the fact that the underlying design is flawed. Really. > If you want to do multiple task management, use a locking mechanism more > suited to the task, like ENQ/DEQ or a spin lock if you can get away with > it. You're comparing apples and fish. Locking has nothing to do with it. Outside of the sup-state-only suspend/resume function, wait/post was the only primitive available for synchronizing separate units of work until the pause/release function came along in OS/390 2.5 or thereabouts. And that one gets the William Tell near-miss award too. But it's a hell of a lot safer for users. Yeah the path length is longer, but so what. > WAIT/POST is virtually identical in functionality to a unix mutex. Single > waiter, single poster. It's efficient and does exactly what it is supposed > to do. Unix is no poster child for coherent design either, but if you think I am arguing that wait/post doesn't work, you have missed my point entirely. My bad. 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
