J. Edler, J. Lipkis, and E. Schonberg. Process management for highly parallel UNIX systems. USENIX Workshop on Unix and Supercomputers, Sep. 1988.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....in a system with one thread per processor, but it fails on multiprogrammed systems, in which a neighbor thread may be preempted, and thus unable to cooperate. Theproblem of preemption in critical sections has received considerable attention over the years. Alternative strategies include avoidance [6, 10, 14], recovery [3, 4] and tolerance [9, 16] The latter approach is appealing for commercial applications because it does not require modification of the kernel interface: if a thread waits too long for a lock, it assumes that the lock holder has been preempted. It abandons its attempt, yields the ....

....synchronization on large multiprogrammed systems. In future work we hope to evaluate our algorithms in the context of commercial OLTP codes. We also plan to develop variants that block in the scheduler on timeout [9, 16] cooperate with the scheduler to avoid preemption while in acritical section [6, 10], or adapt dynamically between test and set and queue based locking in response to observed contention [11] In a related vein, we are developing a tool to help verify the correctness of locking algorithms by transforming source code automatically into input for a model checker. 17 ....

J. Edler, J. Lipkis, and E. Schonberg. Process Management for Highly Parallel UNIX Systems. In Proceedings of the USENIX Workshop on Unix and Supercomputers,Pittsburgh, PA, September 1988.

....relinquish a processor. This mechanism violates the constraint that higher priority threads are always run in place of lower priority threads. Some systems provide asynchronous kernel I O as a mech anism to solve some of the problems with user level thread management on multiprocessors [Edler et al. 88] Weiser et M. 89] Indeed, our work has the flavor of an asynchronous I O system: when an I O request is made, the processor is returned to the application, and later, when the I O completes, the applica.tion is notified. There are two major differences between our work and traditional ....

Edler, J., Lipkis, J., and Schonberg, E. Process Management for Highly Parallel UNIX Systems. In Proceedings of the USENL Workshop on UNIX and Supercomputers, pages 1-17, SepteJnber 1988. /Halstead 85] Halstead, R. Multilisp: A Language for Con- current Symbolic Computation. A CM Transactions on Programming Languages and Systems, 7(4):501-538, October 1985.

....convoying occurs when a lock owner is preempted by the scheduler, and other threads are left spinning for the lock. In Speculative Synchronization, preempting a lock owner prevents speculative threads from committing. A number of techniques have been proposed to avoid preempting a lock owner [6, 17, 24]. Nevertheless, in general, convoying is a concern. On the other hand, TM and SLE share a shortcoming in the presence of conflicts, their speculative mechanisms do not embed a forward progress guarantee. Indeed, since all threads execute the critical section speculatively, any such thread that ....

J. Edler, J. Lipkis, and E. Schonberg. Process management for highly parallel UNIX systems. In USENIX Workshop on Unix and Supercomputers, San Francisco, CA, Sept. 1988.

.... have devised queue based locks in which every process spins on a different, local location, essentially eliminating contention [1, 7, 12] To address the second problem, several operating systems have incorporated schemes in which applications communicate with the kernel scheduler to prevent [6] or recover from [3] preemption in a critical section, or to avoid entering a critical section when preemption is imminent [11] What has not been clear from previous work is how to solve both problems at once. The various mechanisms for dealing with preemption can all be applied in a ....

....both problems at once. The various mechanisms for dealing with preemption can all be applied in a straightforward manner to programs using (test and )test and set locks, resulting in good performance. Their application to programs using queue based locks is much less straightforward. None of [3] [6], and [11] discusses queue based locks, and [12] explicitly recommends non queue based locks for multipro grammed environments. Our contribution in this paper is to demonstrate that simple extensions to the interface of a preemptive scheduler can be combined with an appropriately designed ....

[Article contains additional citation context not shown here]

J. Edler, J. Lipkis, and E. Schonberg. Process Management for Highly Parallel UNIX Systems. In PROC of the USENIX Workshop on Unix and Supercomputers, Pittsburgh, PA, 26-27 September 1988.

....and has advantages for asynchronous IPC, specialized protocols, and multiprocessors, then it is overall a win. However, we do not consider this sufficiently good since synchronous IPC on 2 The race conditions could be resolved with an extended operating system interface [7] For example, SymUnix [2] allows user processes to indicate when they are executing a critical section, and should therefore not be pre empted. void Send( Msg msg, Msg ans ) f void Receive( Msg msg ) f while( enqueue( Q[srv] msg ) while( dequeue( Q[srv] msg ) f sleep( 1 ) queue full Q[srv] awake = ....

J. Edler, J. Lipkis, and E. Schonberg. "Process Management for Highly Parallel UNIX Systems ". In Proc. USENIX Workshop on Unix and SuperComputers, Pittsburgh, PA, Sept 1988.

....time slice quanta based on queue lengths. This approach is well suited to some situations (e.g. audio DSP with little slack CPU time) The deadline workahead scheduling policy is derived from the earliest deadline first policy [9] but differs in its allowance for workahead. In Symunix II [7], parallel applications are implemented as a collection of UNIX processes communicating through shared memory. Processes use virtual preemption masking while holding short duration busy waiting locks and virtual signal masking while updating shared memory. Unlike virtual user interrupt masking, ....

J. Edler, J. Lipkis and E. Schonberg, "Process Management For Highly Parallel UNIX Systems", Proc. of USENIX Workshop on Unix and Supercomputers, September 1988, 1-17.

....on runtime observation of interactions among threads [196, 541] Alternatively, it has been suggested that syntactic program structures can be used to define gangs. Relevant structures are parfor or parbegin in languages like ParC [57] PAR in Occam [285] and the spawn system call in Symunix [182]. Thus, when a set of threads are spawned together by a parallel construct, they are assumed to constitute a gang [438, 197] Coscheduling and family scheduling Two other terms that are often mentioned are coscheduling and family scheduling. Coscheduling 19 was originally defined by Ousterhout ....

....especially the availability of source code) In these systems the unit of parallel execution is typically the Unix process, complete with a separate address space, signal handling facilities, open files, etc. Early examples include multiprocessor Unix systems [37] Symunix on the NYU Ultracomputer [182], and Dynix on the Sequent Balance [570] With the advent of parallel machines based on workstation technology in recent years, this approach has received a new push. For example, the Meiko CS 2, Intel Paragon, and IBM SP2 all run a full Unix system on each node. The problem with Unix processes ....

J. Edler, J. Lipkis, and E. Schonberg, "Process management for highly parallel UNIX systems ". In Proc. Workshop on UNIX and Supercomputers, pp. 1--18, USENIX, Sep 1988.

....switchings on multiprogrammed systems, primarily due to inappropriate interfaces between the kernel and the user level. In most conventional thread mechanisms, threads are implemented solely by the kernel [15, 4, 16, 12] or by user level programs on top of the kernel level threads support [5, 1, 14, 6, 2, 7, 8, 11, 13] (let us call threads implemented by the kernel k threads, and those implemented by user level programs on top of k threads u threads) These thread mechanisms share two characteristics that cause extra switchings: 1) user level programs determine how many k threads to use, and (2) the kernel ....

J. Edler, J. Lipkis, and E. Schonberg, "Process Management for Highly Parallel UNIX Systems," Proceedings of the USENIX Workshop on UNIX and Supercomputers, pp. 1-- 17, Sep. 1988.

....Since the work units in the codes we have used this emulation library for are quite large, it has not been advantageous to use the gang scheduling options that IRIX allows. Gang scheduling schedules all the processes in the share group simultaneously, so they all run or sleep simultaneously [3]. This is not needed in this case, so it can cause the program to require more wallclock time to finish because the share group may be forced to sleep if not all of the processes can be assigned to processors (i.e. if other programs are also running on the machine) 3.8 OS and Processor ....

J. Edler, J. Lipkis, and E. Shonberg. "Process management for highly parallel UNIX systems." Proceedings of the USENIX Workshop on UNIX and Supercomputers, pp 1--17, 1988.

....on runtime observation of interactions among threads [119, 326] Alternatively, it has been suggested that syntactic program structures can be used to define gangs. Relevant structures are parfor or parbegin in languages like ParC [35] PAR in Occam [174] and the spawn system call in Symunix [106]. Thus, when a set of threads are spawned together by a parallel construct, they are assumed to constitute a gang [268, 120] Coscheduling and family scheduling Two other terms that are often mentioned are coscheduling and family scheduling. Coscheduling 14 was originally defined by Ousterhout ....

J. Edler, J. Lipkis, and E. Schonberg, "Process management for highly parallel UNIX systems ". In Proc. Workshop on UNIX and Supercomputers, pp. 1--18, USENIX, Sep 1988.

....activation scheme [ABLL92] sends a software interrupt to a processor of an application when the processor scheduler takes a processor away from it. The application may then choose to continue the preempted process if it was executing code inside a critical section. The Psyche [MSLM91] and Symunix [ELS88] operating systems take the other approach by providing prevention techniques based on improved communication between applications and the scheduler. For example, the Psyche scheduler provides a warning allowing processes to estimate whether the remaining time quanta is sufficient to execute a ....

J. Edler, J. Lipkis, and E. Schonberg. Process management for highly parallel unix systems. In Proceedings of the USENIX Workshop on UNIX and Supercomputers, pages 1--17, September 1988.

.... roughly an order of magnitude more expensive in terms of creation and context switch times [Anderson et al. 1991] The above observations regarding the advantages as well as the limitations of user level threads motivated several system designs to support both kernel level and user level threads [Edler et al. 1988] [Marsh et al. 1991] Anderson et al. 1991] In general, in these designs the kernel provides event notifications to the user level thread management. In Psyche the term thread refers to a user level thread, and the term virtual processor refers to a kernel level thread [Marsh et al. 1991] ....

....in supporting different kinds of thread execution models. These models can differ in terms of scheduling policies, synchronization mechanisms, and thread creation termination models etc. The Symunix design approach is to extend the conventional UNIX environment for largescale parallel machines [Edler et al. 1988]. To support user level thread management it introduces a meta system call to provide an asynchronous interface for making any system call. It also relies on kernel to user space signals for call completion notifications. Anderson et al. developed a user level thread management facility on the DEC ....

[Article contains additional citation context not shown here]

Jan Edler, Jim Lipkis, and Edith Schonberg. Process Management for Highly Parallel UNIX Systems . In USENIX Workshop on Unix and Supercomputers, pages 1--17, September 1988.

....by the MIPS II, PowerPC, and Alpha architectures. 2 Preemption Safe Locking For simple mutual exclusion locks (e.g. test and set) preemption safe locking techniques allow the system either to avoid or to recover from the preemption of processes holding locks. Edler et al. s Symunix system [7] provides an avoidance technique: a process may set a flag requesting that the kernel not preempt it because it is holding a lock. The kernel will honor the request up to a pre defined time limit, setting a second flag to indicate that it did so, and deducting any extra execution time from the ....

....of preemption safe locks. For the designers of future systems, we recommend (1) that hardware always include a universal atomic primitive, and (2) that kernel interfaces provide a mechanism for preemption safe locking. For small scale machines, the Synunix interface appears to work well [7]. For larger machines, a more elaborate interface may be appropriate [12] Quicksort queue 1 2 3 4 5 6 7 8 9 10 11 0.5 1 1.5 2 Processors preemption safe lock ordinary lock MS non blocking 1 2 3 4 5 6 7 8 9 10 11 0.5 1 1.5 2 Processors ordinary lock preemption safe lock MS non blocking 1 2 ....

J. Edler, J. Lipkis, and E. Schonberg. Process Management for Highly Parallel UNIX Systems. In Proceedings of the USENIX Workshop on Unix and Supercomputers, Pittsburgh, PA, September 1988.

....a process to suggest to the scheduler that it be de scheduled in favor of some specific other process, e.g. the holder of a desired lock. Both of these proposals assume that process migration is relatively cheap. Rather than recover from untimely preemption, the Symunix system of Edler et al. [8] and the Psyche system of Marsh et al. 29] provide mechanisms to avoid or prevent it. The Symunix scheduler allows a process to request that it not be preempted during a critical section, and will honor that request, within reason. The Psyche scheduler provides a twominute warning that allows a ....

....the information from the kernel is more accurate than user level estimates, and in part because the kernel can collect the information more efficiently than user level code can guess it. Our kernel extensions are enumerated below. They build upon ideas proposed by the Symunix project at NYU [8]. Similar extensions could be based on the kernel interfaces of Psyche [29] or Scheduler Activations [2] ffl KE 1: For each process the kernel and user cooperate to maintain a variable that represents the process s state and that can be manipulated under certain rules by either. The variable has ....

[Article contains additional citation context not shown here]

J. Edler, J. Lipkis, and E. Schonberg. Process Management for Highly Parallel UNIX Systems. In Proceedings of the USENIX Workshop on Unix and Supercomputers, Pittsburgh, PA, September 1988.

....and recommendations in Section 6. 2 Preemption Safe Locking For simple mutual exclusion locks (e.g. test and set) preemption safe locking techniques allow the system either to avoid or to recover from the adverse effect of the preemption of processes holding locks. Edler et al. s Symunix system [8] employs an avoidance technique: a process may set a flag requesting that the kernel not preempt it because it is holding a lock. The kernel will honor the request up to a pre defined time limit, setting a second flag to indicate that it did so, and deducting any extra execution time from the ....

....but provide dramatic savings on time sliced systems. For the designers of future systems, we recommend (1) that hardware always include a universal atomic primitive, and (2) that kernel interfaces provide a mechanism for preemption safe locking. For small scale machines, the Synunix interface [8] appears to work well. For larger machines, a more elaborate interface may be appropriate [18] We have presented a concurrent queue algorithm that is simple, non blocking, practical, and fast. It appears to be the algorithm of choice for any queue based application on a multiprocessor with a ....

J. Edler, J. Lipkis, and E. Schonberg. Process Management for Highly Parallel UNIX Systems. In Proceedings of the USENIX Workshop on Unix and Supercomputers, Pittsburgh, PA, September 1988.

.... have devised queue based locks in which every process spins on a different, local location, essentially eliminating contention [1, 6, 12] To address the second problem, several operating systems have incorporated schemes in which applications communicate with the kernel scheduler to prevent [5] or recover from [2] preemption in a critical section, or to avoid entering a critical section when preemption is imminent [11] What has not been clear from previous work is how to solve both problems at once. The various mechanisms for dealing with preemption can all be applied in a ....

....various mechanisms for dealing with preemption can all be applied in a straightforward manner to programs using (test and )test and set locks, resulting in good performance, at least on small machines. Their application to programs using queuebased locks is much less straightforward. None of [2] [5], or [11] discusses queue based locks, and [12] explicitly recommends non queue based locks for multiprogrammed environments. Our contribution in this paper is to demonstrate that simple extensions to the interface of a preemptive scheduler can be combined with an appropriately designed ....

[Article contains additional citation context not shown here]

J. Edler, J. Lipkis, and E. Schonberg. Process Management for Highly Parallel UNIX Systems. In Proc. of the USENIX Workshop on Unix and Supercomputers, Pittsburgh, PA, Sep. 1988.

....processes, but they do not address performance degradation due to cache corruption or frequent context switches. A more direct solution is proposed by Zahorjan et al. 265] who describe a thread scheduler that avoids preempting processes inside critical sections. In contrast, Edler et al. [79] propose an approach combining coscheduling and preemption avoidance for critical sections. Multiple processes are combined to form a group. The scheduling policy of a group can be set so that either all processes in the group are scheduled and preempted simultaneously, or individual processes are ....

J. Edler, J. Lipkis, and E. Schonberg. Process management for highly parallel unix systems. In Proceedings of the USENIX Workshop on UNIX and Supercomputers, pages 1--17, September 1988.

....are redistributed among user address spaces. Existing thread mechanisms, however, do not function ideally in a multiprogrammed system. Most existing thread mechanisms implement threads solely with a scheduler in the kernel [1, 2, 3, 4] or in userlevel schedulers on top of the kernel scheduler [5, 6, 7, 8, 9, 10, 11, 12, 13] (let us call threads implemented by the kernel scheduler k threads, and those implemented by user level schedulers u threads in the rest of this paper) Regardless of their different implementation schemes, they share three characteristics that cause unnecessary vertical and horizontal switchings ....

J. Edler, J. Lipkis, and E. Schonberg, "Process management for highly parallel UNIX systems," in Proceedings of the USENIX Workshop on UNIX and Supercomputers, pp. 1--17, September 1988.

....degrades in the presence of multiprogramming under the following circumstances: ffl A process is preempted while holding a lock. This situation arises in both mutual exclusion and reader writer locks when a process is preempted in its critical section. It has been addressed by several researchers [1, 3, 5, 11]. This work was supported in part by National Science Foundationgrants numbers CCR 9319445 and CDA 8822724, by ONR contract number N00014 92 J 1801 (in conjunction with the ARPA Research in Information Science and Technology High Performance Computing, Software Science and Technical program, ....

....on which each process is running or is scheduled to run. It also maintains a generation count for the application s partition. The kernel increments this count each time it changes the allocation of processes to processors. Extensions (1) and (2) are based in part on ideas introduced in Symunix [5], and described in our work on queued locks [14] Extension (3) is a generalization of the interface described in our work on small scale scheduler conscious barriers [7] None of these extensions requires the kernel to maintain information that it does not already have available in its internal ....

J. Edler, J. Lipkis, and E. Schonberg. Process Management for Highly Parallel UNIX Systems. In Proceedings of the USENIX Workshop on Unix and Supercomputers, Pittsburgh, PA, September 1988.

....purpose multi programming operating systems, and general facilities that take into account the special needs of parallel computing. In the area of memory management, there are a number of issues beyond the mere presence of shared memory that must be 4 See [ELS88] for further discussion of these process model issues. addressed. We detail them in the following. 2.1. Shared and private memory Our parallel program model does not preclude hardware isolated (i.e. separately mapped) private memory. Besides the fact that it is necessary for UNIX ....

Edler, J., Lipkis, J., Schonberg, E., "Process Management for Highly Parallel UNIX Systems", Proceedings of USENIX Workshop on UNIX and Supercomputers, September, 1988.

No context found.

J. Edler, J. Lipkis, and E. Schonberg. Process management for highly parallel UNIX systems. USENIX Workshop on Unix and Supercomputers, Sep. 1988.

No context found.

Jan Edler, Jim Lipkis, and Edith Schonberg. Process management for highly parallel UNIX systems. In Proc. of the USENIX Workshop on Unix and Supercomputers, Pittsburg, PA, September 26--27 1988.

No context found.

J. Edler, J. Lipkis, and E. Schonberg. "Process Management for Highly Parallel UNIX Systems". Technical Report Ultracomputer Note 136, Ultracomputer Research Laboratory, New York University, Apr 1988.

No context found.

Edler et al., "Process Management for Highly Parallel UNIX Systems ", USENIX Workshop on UNIX and Supercomputers, September 1988.

No context found.

Jan Edler, Jim Lipkis, and Edith Schonberg, "Process Management for Highly Parallel UNIX Systems", Proc. Usenix Workshop on UNIX and Supercomputers, Pittsburgh, 1988a, pp. 1-17.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC