billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (03/31/89)
From article <796@aber-cs.UUCP>, by pcg@aber-cs.UUCP (Piercarlo Grandi): > In article <9274@claris.com> peirce@claris.com (Michael Peirce) writes: > >2. When a task has completed its execution, termination is delayed until all > > dependent tasks have terminated (9.4.6). As a result, our program > > fills up all memory with completed tasks unable to terminate. Why is > > this? Can something be done about it (without altering task dependency)? > > The way we dealt with this problem was to reuse our tasks. We had > a situation where we wanted to dispatch a handler task for each incoming > request from the network. In Vax Ada, the tasks weren't removed from > memory until after the program exited the scope of the task declaration. > % This is all nice and true, but of course hardly satisfactory. It essentially % defeats the idea of using dynamically created tasks. [...] % % There is another problem with Ada tasking, and it is well known to those % who know OS/MVS and IMS. When an Ada task takes a page fault, the entire % address space is suspended waiting for resolution of the page fault; % another Ada task is not redispatched, even if it could, because on virtually % all the Ada implementations I know of (notably the VMS one) the OS does not % know about Ada tasks at all. [...] % % There are only two solutions, one fairly horrible, having a signal delivered % by the OS on a page fault to the in-address space scheduler, the second % and proper one is to have threads in the OS and associated Ada tasks with % the threads. Unfortunately the second one can be fairly expensive, many % systems have high overhead threads (e.g. OS/MVS). Similar problems have plagued those who try to do multitasking in other languages as well. The "task reuse" solution has been the most popular workaround. But Ada tasking is not at fault: the problem lies solely with the OPERATING SYSTEMS. They use up large amounts of time modifying various data structures every time a process is created, and do this blindly without engaging in the task reuse optimization that application programmers are now having to program ON TOP OF the operating system. So why aren't these operating systems being UPGRADED to support current applications programming requirements??? Bill Wolfe, wtwolfe@hubcap.clemson.edu
rjh@cs.purdue.EDU (Bob Hathaway) (04/04/89)
>% There is another problem with Ada tasking, and it is well known to those >% who know OS/MVS and IMS. When an Ada task takes a page fault, the entire >% address space is suspended waiting for resolution of the page fault; >% another Ada task is not redispatched, even if it could, because on virtually >% all the Ada implementations I know of (notably the VMS one) the OS does not >% know about Ada tasks at all. [...] >% >% There are only two solutions, one fairly horrible, having a signal delivered >% by the OS on a page fault to the in-address space scheduler, the second >% and proper one is to have threads in the OS and associated Ada tasks with >% the threads. Unfortunately the second one can be fairly expensive, many >% systems have high overhead threads (e.g. OS/MVS). > > > Similar problems have plagued those who try to do multitasking in > other languages as well. The "task reuse" solution has been the > most popular workaround. But Ada tasking is not at fault: the > problem lies solely with the OPERATING SYSTEMS. They use up > large amounts of time modifying various data structures every time > a process is created, and do this blindly without engaging in the > task reuse optimization that application programmers are now having > to program ON TOP OF the operating system. > > So why aren't these operating systems being UPGRADED to > support current applications programming requirements??? > > Bill Wolfe, wtwolfe@hubcap.clemson.edu Actually, they are. BiiN has an Ada based operating system designed to support tasking and operating systems based on the Mach kernel can also provide full support for tasking (both systems also support distributed programming). Since a cactus stack architecture provides the most natural implementation of the Ada tasking model and virtual machine, a fault in a lightweight process'es stack address space should not interfere with execution of other tasks in the program and I don't see why page faults in other regions of the address space should cause suspension of all related threads of control either. Anyway, since modern operating systems are designed to support threads (Ada tasks) within heavyweight processes overhead should be minimal, especially when compared to the heavyweight context switching and high process creation cost typical in a tool-based environment. When programming with the Unix interface, the two features most notably lacking are support for lightweight processes and distributed programming. These are usually left to specific vendors to provide leaving compiler writers and distributed programmers with implementation specific programming. Standards in these areas are *definitely* needed. As frequently pointed out, since multi-processors provide hardware support for concurrent programming and Ada is a concurrent programming language, the popular operating systems seem to be the bottleneck in the middle and updated operating system standards should provide the answer. I haven't looked at the POSIX standard yet but I'm hoping support for lightweight processes and distributed programming is provided. Bob Hathaway rjh@purdue.edu
rjh@cs.purdue.EDU (Bob Hathaway) (04/04/89)
(Please excuse if this is sent twice, the first try didn't appear to succeed) >% There is another problem with Ada tasking, and it is well known to those >% who know OS/MVS and IMS. When an Ada task takes a page fault, the entire >% address space is suspended waiting for resolution of the page fault; >% another Ada task is not redispatched, even if it could, because on virtually >% all the Ada implementations I know of (notably the VMS one) the OS does not >% know about Ada tasks at all. [...] >% >% There are only two solutions, one fairly horrible, having a signal delivered >% by the OS on a page fault to the in-address space scheduler, the second >% and proper one is to have threads in the OS and associated Ada tasks with >% the threads. Unfortunately the second one can be fairly expensive, many >% systems have high overhead threads (e.g. OS/MVS). > > > Similar problems have plagued those who try to do multitasking in > other languages as well. The "task reuse" solution has been the > most popular workaround. But Ada tasking is not at fault: the > problem lies solely with the OPERATING SYSTEMS. They use up > large amounts of time modifying various data structures every time > a process is created, and do this blindly without engaging in the > task reuse optimization that application programmers are now having > to program ON TOP OF the operating system. > > So why aren't these operating systems being UPGRADED to > support current applications programming requirements??? > > Bill Wolfe, wtwolfe@hubcap.clemson.edu Actually, they are. BiiN has an Ada based operating system designed to support tasking and operating systems based on the Mach kernel can also provide full support for tasking (both systems also support distributed programming). Since a cactus stack architecture provides the most natural implementation of the Ada tasking model and virtual machine, a fault in a lightweight process'es stack address space should not interfere with execution of other tasks in the program and I don't see why page faults in other regions of the address space should cause suspension of all related threads of control either. Anyway, since modern operating systems are designed to support threads (Ada tasks) within heavyweight processes overhead should be minimal, especially when compared to the heavyweight context switching and high process creation cost typical in a tool-based environment. When programming with the Unix interface, the two features most notably lacking are support for lightweight processes and distributed programming. These are usually left to specific vendors to provide leaving compiler writers (or RTS implementors :-)) and distributed programmers with implementation specific programming. Standards in these areas are *definitely* needed. As frequently pointed out, since multi-processors provide hardware support for concurrent programming and Ada is a concurrent programming language, the popular operating systems seem to be the bottleneck in the middle and updated operating system standards should provide the answer. I haven't looked at the POSIX standard yet but I'm hoping support for lightweight processes and distributed programming is provided. Bob Hathaway rjh@purdue.edu
linimon@killer.Dallas.TX.US (Mark Linimon) (04/05/89)
In article <6376@medusa.cs.purdue.edu>, rjh@cs.purdue.EDU (Bob Hathaway) writes: > > So why aren't these operating systems being UPGRADED to > > support current applications programming requirements??? > > Actually, they are. There are (in addition to the article posted) ast least two versions of ADA intended to run on embedded systems that support lightweight threads. Mark Linimon Mizar, Inc. uucp: {sun!texsun, convex, killer}!mizarvme!linimon