kornegay@oiscola.Columbia.NCR.COM (h) (01/09/91)
I have looked at the CMA threads package as a potential means to execute multi-threaded software under Unix. I need threads to have the following semantics: a thread executing a blocking system call (eg: read(...)) should only block itself and allow other threads to continue to execute, and preemptive scheduling of threads allowing the currently executing thread to be preempted if a higher priority thread becomes ready. CMA threads do not have this functionality. My questions are: How are users of CMA threads achieving parallelism in their code when blocking system calls are neccessary or desirable? Are alternate libraries providing non-blocking versions of the system calls used that are compatible with CMA's model of threads? Do you HAVE to resort to using O_NDELAY and busy wait loops when to avoid blocking system calls? Etc? Any info or suggestions would be appreciate, thanks. -- ---------- Michael L. Kornegay, kornegay@oiscola.columbia.ncr.com
fkittred@bbn.com (Fletcher Kittredge) (01/10/91)
In article <331@oiscola.Columbia.NCR.COM> kornegay@oiscola.UUCP (Michael L. Kornegay) writes: >I have looked at the CMA threads package as a potential means to >execute multi-threaded software under Unix. I need threads to have >the following semantics: a thread executing a blocking system call >(eg: read(...)) should only block itself and allow other threads to >continue to execute, and preemptive scheduling of threads allowing >the currently executing thread to be preempted if a higher priority >thread becomes ready. CMA threads do not have this functionality. > How soon do you need this functionality and how good are your connections? OSF/1 has this functionality in the form of a POSIX 1003.4a Draft 4 threads package and (I think) the Mach C-threads package. OSF/1 is currently available from OSF for the DECStation. DEC is selling developer's versions of OSF/1 this quarter, and the Ultrix/OSF merge is due out this year. If you know the right people in DEC or the OSF, then you should be able to get OSF/1 pretty quickly. My understanding is that CMA is going to be replaced by Pthreads. We are aiming our (extensive) threads development at that enviroment. You could also get the Mach 3.0 micro-kernel free from CMU, but you need full Unix source licenses to do anything useful with it. regards, fletcher Fletcher Kittredge Platforms and Tools Group, BBN Software Products 10 Fawcett Street, Cambridge, MA. 02138 617-873-3465 / fkittred@bbn.com / fkittred@das.harvard.edu
billmers@merlyn.enet.dec.com (Meyer Billmers) (01/10/91)
> My understanding is that CMA is going to be replaced by Pthreads. We are > aiming our (extensive) threads development at that enviroment. Pardon my ignorance (for that's probably what it is), but isn't CMA part of OSF's Distributed Computing Environment (DCE)? If so, how could OSF/1 using something else (e.g. Pthreads)?
jg@quabbin.crl.dec.com (Jim Gettys) (01/10/91)
In article <18809@shlump.nac.dec.com> billmers@merlyn.enet.dec.com (Meyer Billmers) writes: >> My understanding is that CMA is going to be replaced by Pthreads. We are >> aiming our (extensive) threads development at that enviroment. > >Pardon my ignorance (for that's probably what it is), but isn't CMA part of >OSF's Distributed Computing Environment (DCE)? If so, how could OSF/1 using >something else (e.g. Pthreads)? You are correct; CMA is part of DCE. But there is no conflict here; pthreads has been influenced by the CMA work, and it is a simple matter of programming interfaces, as I understand it, rather than significant functionality differences. I'm not expert in these matters, but I don't know if any of the people working on CMA read this group (particularly since they have to get the OSF the code sometime around now, from what I remember). - Jim -- Digital Equipment Corporation Cambridge Research Laboratory
fkittred@bbn.com (Fletcher Kittredge) (01/11/91)
In article <18809@shlump.nac.dec.com> billmers@merlyn.enet.dec.com (Meyer Billmers) writes: >> My understanding is that CMA is going to be replaced by Pthreads. We are >> aiming our (extensive) threads development at that enviroment. > >Pardon my ignorance (for that's probably what it is), but isn't CMA part of >OSF's Distributed Computing Environment (DCE)? If so, how could OSF/1 using >something else (e.g. Pthreads)? This is a *VERY* good question which I have asked myself. It goes with the question "Doesn't Mach IPC make DCE NCS redundant on OSF/1?" The best answer I can come up with is that CMA and NCS are meant for environments other than OSF/1 for people whom want a system that will work in a VMS or PC environment. Another likely scenerio is that the architecture of DCE was defined before Mach and Pthreads were chosen for OSF/1. regards, fletcher Fletcher Kittredge Platforms and Tools Group, BBN Software Products 10 Fawcett Street, Cambridge, MA. 02138 617-873-3465 / fkittred@bbn.com / fkittred@das.harvard.edu
nick@osf.org (Nick Dokos) (01/11/91)
My understanding is that the architecture does not specify the degree of parallelism but strongly encourages the thread-synchronous model (only the thread executing the blocking call is blocked). Quoting from the CMA document (Ch. 6: Operating System Support for CMA Services, p.71): " A reentrant service is thread-serial if, when it must block, it blocks the current thread and all other threads that might attempt to call the same service until the first call returns. A reentrant service is said to be thread-synchronous if, when it must block, it blocks only the current thread, and other threads can execute the same operation during the blockage. For many services, providing thread-serial reentrancy is adequate, but implementations should try hard to provide thread-synchronous I/O services (any service with a long latency is best made thread synchronous). This is more work than merely making services serially reentrant, but it is urgently needed by I/O intensive applications." In other words, blame the implementation :-) BTW, what implementation are you using and on what version of Unix? Same is true of the scheduling policy: the architecture provides for the most rudimentary scheduling controls and leaves the detailed properties of scheduling to the implementation (p.8 of the CMA doc). -- Nick Dokos (nick@osf.org) Systems Engineering OSF