* Ada and Unix Sockets @ 1990-11-19 4:15 Bradley Schmerl 1990-11-20 20:58 ` Paul Stachour 1990-11-26 12:34 ` Ada and Unix Sockets Dennis Gibbs 0 siblings, 2 replies; 6+ messages in thread From: Bradley Schmerl @ 1990-11-19 4:15 UTC (permalink / raw) Greetings, I am writing a program in Ada which uses a blend of X events and socket communication with other ada programs. I am running into a problem doing this, because when a call is made to wait for a socket (or get the next X Event), the whole Ada program (only one Unix process) blocks, and so other tasks don't continue running. Is there any way of overcoming this problem, apart from using a busy loop to continually poll for events? Oh, I am using Verdix Ada 5.5 on an Encore MultiMax under Unix. Could you also e-mail me directly, as I don't read this newsgroup often. Bradley. -- bradley@cs.adelaide.edu.au ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Ada and Unix Sockets 1990-11-19 4:15 Ada and Unix Sockets Bradley Schmerl @ 1990-11-20 20:58 ` Paul Stachour 1990-11-21 16:05 ` Ada and OS tasks (was Ada and Unix Sockets) Jerry Callen 1990-11-26 12:34 ` Ada and Unix Sockets Dennis Gibbs 1 sibling, 1 reply; 6+ messages in thread From: Paul Stachour @ 1990-11-20 20:58 UTC (permalink / raw) bradley@chook.adelaide.edu.au (Bradley Schmerl) writes: > I am writing a program in Ada which uses a blend of X events > and socket communication with other ada programs. I am running into > a problem doing this, because when a call is made to wait for a socket > (or get the next X Event), the whole Ada program (only one Unix process) > blocks, and so other tasks don't continue running. Is there any way > of overcoming this problem, apart from using > a busy loop to continually poll for events? > Could you also e-mail me directly, as I don't read this newsgroup > often. This is a rather "standard" problem. One has to begin by thinking in a concurrent mode. We note that many OS'es don't have tasks (e.g., MSDOS) and others don't have threads(e.g, most unixes). What you are looking for is an OS that has threads (also-known-as thin or weak processes) and and Ada Compiler that implements each task as a thread. Any Ada compiler builder has a dilema to overcome, namely: "Is an Ada Task a OS Process or not?" If the answer is "Yes", i.e., an Ada task is an OS process, then: In some OS'es, there is a problem of sharing memory. In some OS'es, there is an interrupt handling problem. In some OS'es, the context-switch it too long. In some OS'es, one can't implement certain rendesvous cheaply. If the answer is "No", i.e., a whole Ada program (multiple Ada tasks) is one OS process, then: In some OS'es, there is a blocking of all tasks when a program does IO. In some OS'es, there is a blocking of all tasks when a program does an OS Service call. In some OS'es, there is a blocking of all tasks when a program calls some service subprogram that ... [Your case] Let's face it, most interfaces are NOT designed in an asynchronous manner, where one sets-off a request, and then checks-back to see if it is done. [The IO requests in IBM's OS/360 and followon lines are a good example of doing it "right" from a tasking point-of-view, but it is OS/MVT]. Stepping back a moment, does the Ada compiler vendor have a responsibility to ensure that ALL subroutines you call from your Ada program behave responsibly? No, that responsibility is only for TEXT_IO and other native-Ada packages. What would I do? Given that the subroutine is non-Ada (if it is Ada then the subroutine implementor has a duty), I would have to step-out of Ada and create another OS-process. I then need that OS process to issue the sockets [or whatever] call; thus blocking. And have it send my Ada program a message with the OS message service, or use shared memory, or something similar, when the service was completed. ...Paul -- Paul Stachour Secure Computing Technology Corp stachour@sctc.com 1210 W. County Rd E, Suite 100 Arden Hills, MN 55112 [1]-(612) 482-7467 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Ada and OS tasks (was Ada and Unix Sockets) 1990-11-20 20:58 ` Paul Stachour @ 1990-11-21 16:05 ` Jerry Callen 1990-11-23 13:19 ` Ada and OS tasks Jean-Loup Gailly 0 siblings, 1 reply; 6+ messages in thread From: Jerry Callen @ 1990-11-21 16:05 UTC (permalink / raw) In article <1990Nov20.205819.24040@sctc.com> stachour@sctc.com (Paul Stachour) writes: >[ Interesting article on whether or not Ada runtimes should map Ada tasks to underlying OS tasks/thread/processes/etc. ] I've worked on Ada runtimes that did it both ways. Generally, you have more flexibility if Ada tasks use the underlying OS tasks, but you pay a price in overhead; how much depends upon the system. Paul missed a few issues; here are some more: - The underlying OS may not provide much, if any, control over task scheduling, which renders Ada priorities meaningless. - The OS may not provide much in the way of locking primitives; building your own (with, say test and set and spin locks) may prove problematic. For instance, suppose a task holding a lock is blocked by the OS and another task tries to get the lock? You can burn a lot of CPU in spin locks. This is important because a multi-threaded Ada RTS is going to make heavy use of locking. - How do Text_IO and the other predefined Ada I/O packages behave in the presense of tasks? Making them "do the right thing" may entail a lot of overhead that most programs don't need. (My vote: control via the forms string.) So how have various Ada implementations done it? Here are a few I am familiar with; I'd love to see folks post more. I have a lot of IBM/370 experience, which is reflected in the following list... - Intermetrics MVS Ada: one Ada task per MVS task. Task create times are unpleasantly long, but rendezvous isn't bad; as Paul pointed out, all I/O in MVS is inherently asynchronous, so the OS provides reasonably efficient "wait/post" primitives. Since MVS runs on multiprocessors, it is possible to really have multiple Ada tasks executing simultaneously. Shared memory isn't a problem since MVS tasks share an address space. - Intermetrics CICS Ada: one Ada task per CICS task. I don't have any idea how well it performs. - Telesoft MVS Ada: mapping controlled by pragma; I don't have details. I would expect the performance to be similar to the Intermetrics RTS (at least regarding OS task create/rendezvous times). - current Encore Ada (uses Verdix technology): two schemes available. The "sequential" Ada is the usual "one Unix process for the whole program" approach, with the Ada RTS handling dispatching. The "parallel" Ada allows a variable number of Unix processes to be allocated to a program, which the RTS multiplexes among the Ada tasks; it's sort of a hybrid of the two usual approaches. Memory is shared via Unix shared memory facilities. I/O is funnelled through a single I/O process. - forthcoming Encore Ada (for Encore 88K based systems): one "very lightweight process" (thread, really) per Ada task. All threads share an address space. I'm currently working on this implementation; needless to say, it runs like a bat outta hell. :-) -- Jerry Callen jcallen@encore.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Ada and OS tasks 1990-11-21 16:05 ` Ada and OS tasks (was Ada and Unix Sockets) Jerry Callen @ 1990-11-23 13:19 ` Jean-Loup Gailly 0 siblings, 0 replies; 6+ messages in thread From: Jean-Loup Gailly @ 1990-11-23 13:19 UTC (permalink / raw) In article <13325@encore.Encore.COM>, jcallen@Encore.COM (Jerry Callen) writes: > I've worked on Ada runtimes that did it both ways. Generally, you have more > flexibility if Ada tasks use the underlying OS tasks, but you pay a price in > overhead; how much depends upon the system. Quite correct. I have also worked (within Alsys) on Ada runtimes that did it both ways. When Ada tasks are mapped to OS threads, the rendezvous time is usually dominated by the time spent in the OS, even when the Ada runtime does its best to minimize the number of system calls. > - The OS may not provide much in the way of locking primitives; building your > own (with, say test and set and spin locks) may prove problematic. For > instance, suppose a task holding a lock is blocked by the OS and another > task tries to get the lock? You can burn a lot of CPU in spin locks. > > This is important because a multi-threaded Ada RTS is going to make > heavy use of locking. Yes, spin locks should not be used, but there are other alternatives. You can build a very fast locking primitive by making an (expensive) blocking system call only in the case of contention, that is, when a test-and-set fails. Variants of this scheme are used in the Alsys Ada runtimes which map tasks onto OS threads, and in the implementation of mutexes in the Chorus operating system. > So how have various Ada implementations done it? Here are a few I am > familiar with; I'd love to see folks post more. - Alsys MVS Ada: mapping controlled by pragma and binder options. A variable number of MVS tasks can be allocated, each running a variable number of Ada tasks. So both extremes are possible (all Ada tasks mapped to one MVS task, or one Ada task per MVS task). - Alsys Ada on LynxOS: the current implementation supports only the one to one mapping between Ada tasks and LynxOS threads. - Alsys Ada on VRTX: also one to one mapping. - Alsys Unix compilers: the usual "one Unix process for the whole program". Predefined IO "does the right thing", that is, one task blocked on IO does not block other tasks. However non predefined IO (such as sockets) is blocking. Jean-loup Gailly E-mail: jloup@chorus.fr Chorus systemes, 6 avenue Gustave Eiffel Fax: +33 (1) 30 57 00 66 78182, St-Quentin-en-Yvelines-Cedex Tel: +33 (1) 30 64 82 79 France ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Ada and Unix Sockets 1990-11-19 4:15 Ada and Unix Sockets Bradley Schmerl 1990-11-20 20:58 ` Paul Stachour @ 1990-11-26 12:34 ` Dennis Gibbs 1990-11-29 22:59 ` Jean-Marc Alliot 1 sibling, 1 reply; 6+ messages in thread From: Dennis Gibbs @ 1990-11-26 12:34 UTC (permalink / raw) In article <1873@sirius.ucs.adelaide.edu.au>, bradley@chook.adelaide.edu.au (Bradley Schmerl) writes: > > I am writing a program in Ada which uses a blend of X events and socket > communication with other ada programs. I am running into a problem doing this, > because when a call is made to wait for a socket (or get the next X Event), the > whole Ada program (only one Unix process) blocks, and so other tasks don't > continue running. Is there any way of overcoming this problem, apart from using > a busy loop to continually poll for events? > > Bradley. > bradley@cs.adelaide.edu.au Bradley, Could you email me the replies you get to your posting to comp.lang.ada regarding Ada and Unix Sockets? We are experiencing the same exact problem (Ada tasks get blocked while waiting for events) and I don't know yet how to solve this either! Any replies you get that you could send me would be most appreciated...Meanwhile if I uncover any solutions I'll send them your way.... Thanks! Dennis Gibbs TRW Systems Integration Group (703) 802-1961 ...uunet!tfsg!dennis P.S. I tried email to you but it bounces..... ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Ada and Unix Sockets 1990-11-26 12:34 ` Ada and Unix Sockets Dennis Gibbs @ 1990-11-29 22:59 ` Jean-Marc Alliot 0 siblings, 0 replies; 6+ messages in thread From: Jean-Marc Alliot @ 1990-11-29 22:59 UTC (permalink / raw) Our news system broke off last week and I didn't get the address of the poster of the query. So I'm posting this answer directly to the net. We experiened the same rpoblem using ADA-ALSYS compiler and UNIX sockets on a SUN (3.5, 4.0 and 4.1 OS). The reason is quite easy to understand. Every ADA task belongs to the same UNIX process. And any system call (like read, write or accept) is blocking (by default), and blocking for the WHOLE UNIX process. So every task is automatically blocked. Solving completely the problem was quite difficult. We had to mask the UNIX OS, and it ended in more than 5000 lines of ADA code. The packages are now efficient and probably portable on any BSD-based system. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1990-11-29 22:59 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1990-11-19 4:15 Ada and Unix Sockets Bradley Schmerl 1990-11-20 20:58 ` Paul Stachour 1990-11-21 16:05 ` Ada and OS tasks (was Ada and Unix Sockets) Jerry Callen 1990-11-23 13:19 ` Ada and OS tasks Jean-Loup Gailly 1990-11-26 12:34 ` Ada and Unix Sockets Dennis Gibbs 1990-11-29 22:59 ` Jean-Marc Alliot
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox