The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Farley, Peter x23353) writes: > Granted, but the converse is also true: A posix-style semaphore or > queuing mechanism is way overkill for the simplest cases, which IMHO > most non-software-house application (not systems) programmers are most > likely to need or encounter. > > Typical in my non-software-house application experience is a single > master task with N children, each child with different responsibilities, > and each child's only communication need is with the parent, not with > any sibling. In this type of application, ECB/POST/WAIT is more than > adequate and no requests are ever lost using FastPOST or FastWAIT. > > Software houses and systems programmers tend to deal with far more > complex designs where multiple requestors and/or multiple servers are > involved. For those applications a semaphore or queuing mechanisms of > some sort are certainly the correct solution. BTDTGTTSTPI. > > IOW, suit the tool to the job you need to accomplish. ECB/POST/WAIT is > a perfectly proportioned mechanism for even quite sophisticated > application programming. It's only when you must step up to the next > level of multiple requestor/server designs that ECB/POST/WAIT becomes > insufficient to your application's needs. all of the large DBMS vendors have gone to some sort of internal task management ... and are using compare&swap ... or similar instruction from other hardware vendors (that would offer similar semantics, although the 370 compare&swap is the granddaddy). one of the problems that rs/6000 and aix ran into getting all the major vendors to port to the RS/6000 and aix ... was that it failed to have an instruction offering compare&swap atomic semantics ... forcing (by comparison) significant performance degradation (using kernel calls). It was possibly initially anticipated that RS/6000 didn't require a compare&swap instruction because the rios/power chip didn't offer a multiprocessor option. however, one of the first AIX "enhancements" for the major DBMS vendors was an emulated compare&swap instruction ... which translated into an SVC call with an extremely short instruction emulation fastpath in the supervisor call first level interrupt handler ... with immediate return to application mode. rios/power was always only a single processor but needed to run disabled for all interrupts to provide the emulated atomic compare&swap semantics ... and do it with minimal pathlength overhead (thus the special case emulation and return done totally in the svc interrupt handler). there is significant amount of commonality in design across the dbms industry on how to leverage compare&swap semantics to implement multithreaded/multitasking operation. lots of past posts mentioning multiprocessor designs and implementations and/or compare&swap instruction http://www.garlic.com/~lynn/subtopic.html#smp things get more complex going to cluster (loosely-coupled) operation. my wife had been con'ed into going to POK to be in charge of loosely-coupled architecture. while there, she came up with peer-coupled shared data architecture ... which didn't see a lot of takeup until sysplex (which contributed to her not staying long in the position) ... except for the people doing ims hotstandby ... misc. past posts http://www.garlic.com/~lynn/subtopic.html#shareddata later we did the ha/cmp product http://www.garlic.com/~lynn/subtopic.html#hacmp with a distributed lock manager that managed serialization function & transaction semantics across a clustered, loosely-coupled environment. we had extended the work in ha/cmp and distributed lock manager for large-scale scaleup ... mentioned in this old post http://www.garlic.com/~lynn/95.html#13 and some of the scaleup issues discussed in these old emails http://www.garlic.com/~lynn/lhwemail.html#medusa ---------------------------------------------------------------------- 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
