sweiger@sequent.UUCP (Mark Sweiger) (11/11/89)
Dan Weinreb (dlw@odi.com) writes the following regarding multithreading client/server DBMS architectures on Unix multiprocessor platforms: (1) Every serious multiprocessor Unix vendor provides some way to run truly concurrent threads within a single Unix process; however, the details of how this work differ from one vendor to another. (2) There are serious multiprocessor Unix vendors who do not provide any way to run truly concurrent threads within a single Unix process. If (1) is the case, it seems that it would not be very hard to provide a small software layer that would hide the differences between the various operating systems. Then porting would require writing a new version of this layer, sort of like writing a new device driver for a new kind of disk, but it would be pretty easy. The Unix International (UI) threading standard, which is destined to become part of the POSIX industry group Unix standard, implies that threading on multiprocessors should be truly concurrent (that is, individual threads can execute concurrently on each of the multiple processors). This means that POSIX compliant vendors (Sequent is one of them) will offer a standard form of concurrent threading when they finally get finished implementing the feature. If RDBMS software took advantage of UI standard multithreading on multiprocessors, not only would it get concurrent thread execution and the load balancing advantages of symmetric multiprocessor scheduling, but it would also get shared memory mapping and shared file descriptors for free, which is a benefit threads have over normal Unix processes. Now, will multithreading implemenations actually adhere to the emerging standards, or will they be homebrew? The trend seems to be a bit of both. If a standard implementation offers some compelling advantages over homebrew, it tends to get adopted. For example, the concurrently executing threads of the UI standard for multiprocessors offer a significant advantage over the non-concurrent threads of homebrew implementations. So, as you pointed out, the real key in implementing portable multithreading in RDBMS software is to isolate the threading code (scheduling, thread creation, thread deletion, etc.). I have personally witnessed a conversion from homebrew to OS/2 threads on one RDBMS product, and it took one man about 6 months to do it. After having done this port to OS/2, the implementor assures me that the threading interface is even more isolated than before, and next time it will be even easier to port to a different environment. -- Mark Sweiger Sequent Computer Systems Database Software Engineer 15450 SW Koll Parkway Beaverton, Oregon 97006-6063 (503)526-4329 ...{tektronix,ogcvax}!sequent!sweiger