B. Lampson and D. Redell. Experience with Processes and Monitors in Mesa. Communications of the ACM, pages 105--117, February 1980.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....large. The main shortcoming of these techniques is that they lack the flexibilitytoprovide a general framework for object sharing in real time systems. Lampson and Redell were the first to recognize priority inversion as a problem associated with using lock based objects in priority based systems [55]. A priority inversion occurs when a task is delayed byalower priority task that is inside a critical section. This problem is illustrated in Figure 2.2(a) In Figure 2.2, up arrows and down arrows indicate task invocations and task completions, respectively. Tasks are indexed in the order of ....

....rest of this section deals with mechanisms for reducing blocking factors in lock based schemes. Lampson and Redell were the first to solve the priority inversion problem using kernel support by associating with each resource R the priority of the highest prioritytask that may lock that resource [55]. The priority of any task that accesses resource R is elevated to the priority associated with that resource. However, Lampson and Redell s work was targeted for the Mesa programming language# they did not provide a general solution to the priorityinversion problem. Later, Sha, Rajkumar, and ....

[Article contains additional citation context not shown here]

B. W. Lampson and D. D. Redell. Experiences with processes and monitors in mesa. Communications of the ACM, 23(2):105--117, 1980.

....broken down into aperiodic tasks, the latter approach is much simpler to implement. Extensive work has focussed on schedulability analysis for aperiodic servers in hard real time systems in the presence of resource constraints. The priority inversion problem due to blocking was first mentioned in [9]. In [17] Sha et al. proposed modifications to schedulability tests for using utilization bounds derived by Liu and Layland [11] to guarantee schedulability of periodic tasks using the priority ceiling protocols by the rate monotonic algorithm. Work by Ghazalie and Baker [7] take into account ....

B. W. Lampson and D. D. Redell. Experiences with processes and monitors in mesa. Communications of the ACM, February 1980.

....is simple: given a set of processes with assigned priorities, run the process with the highest priority. However, when processes share resources, resource dependencies among processes can arise that prevent the scheduler from running the highest priority process, resulting in priority inversion [1]. For example, suppose there are three processes with high, medium, and low priority such that the high priority process is blocked waiting for a resource held by the low priority process. A priority scheduler would run the medium priority process, preventing the low priority process from running ....

....the NASA Mars Pathfinder rover [2] when priority inversion caused repeated system resets and drastically limited its ability to communicate back to the Earth. Because the negative impact of priority inversion can be significant, much work has been done to address this resource management problem [1, 3, 4, 5, 6]. The general idea behind these approaches is to boost the priority of a low priority process holding the resource so that it can run and release the resource to get out of the way of a high priority process waiting on the resource to run. However, there are four important limitations that occur ....

[Article contains additional citation context not shown here]

B. W. Lampson and D. D. Redell, "Experience with processes and monitors in Mesa," Communications of the ACM, vol. 23, pp. 105--117, Feb. 1980.

....thread tunnelling approach being somewhat more practical in Rcane than in Nemesis. 5.6.2 Priority Inversion Notwithstanding the arguments presented in the previous sections, thread tunnelling is not without potential pitfalls. One of the most obvious is that of priority inversion, identified in [Lampson80]. This can occur when a client thread with limited resources is executing within a mutual exclusion region. In a traditional system using priorities rather than guarantees, priority inversion may lead to long term starvation if a high priority thread wishes to enter the mutual exclusion ....

.... provided that the server itself has su#cient resources guaranteed to it that it is not starved by other applications but it should be noted that any system that combines the provision of resource guarantees with mutually exclusive access to shared resources will su#er from similar problems. [Lampson80] proposes priority inheritance as a solution to the problem of priority inversion: whenever a thread holds the lock on a mutual exclusion region, it runs with the highest priority of any thread waiting to enter the region. A similar approach is proposed in [Waldspurger94] using the transfer of ....

[Article contains additional citation context not shown here]

Butler W. Lampson and David D. Redell. Experience with Processes and Monitors in Mesa. Communications of the ACM, 23(2):105--117, February

....and on the lack of virtual memory, since a page fault should not occur within an atomic section. However, these assumptions can be relaxed by considering alternate implementations of atomic sections, for example, using non blocking synchronization primitives [15] The use of monitors in Mesa [26] is the most directly comparable concurrency model to ours. In Mesa, the authors considered and rejected atomicity based on non preemption for several reasons, including the desire to support multiprocessors and virtual memory. Also, non preemption alone does not handle interrupts; we use atomic ....

B. W. Lampson and D. D. Redell. Experience with processes and monitors in mesa. In Proceedings of the 7th ACM Symposium on Operating Systems Principles (SOSP), pages 43--44, 1979.

....cannot proceed because the lock is not free. This results in convoying. Convoying occurs when a convoy of waiting threads is formed and the lock for which these threads are waiting will not be available for a while.This may result in a critical problem of priority inversion if one is not careful [104]. Further, if a thread terminates due to an error while holding a lock, other threads waiting for the lock never complete as the lock is never free again. The problem is catastrophic in a transaction oriented environment where threads are largely independent except while accessing some critical ....

Butler W. Lampson and David D. Redell. Experiences with Processes and Monitors in Mesa. Communications of the ACM, 22(2):105--117, February 1980.

....than the model found in Java, at little or no additional cost in execution time. The synchronization optimizations we describe enable programmers to design efficient, reusable and maintainable libraries and systems in Java without cumbersome manual code restructuring. 1. Introduction Monitors [LR80] are appealing constructs for synchronization, because they promote reusable code and present a simple model to the programmer. For these reasons, several programming languages, such as Java [GJS96] and Modula 3 [H92] directly support them. However, widespread use of monitors can incur ....

B. Lampson and D. Redell. Experience with Processes and Monitors in Mesa. In Communications of the ACM: 23(2), February 1980.

....with multiple inheritance. Mitt86 Stef83] Mach: Capability based Unix for object oriented programming. Carnegie Mellon. Jone86] Mesa: Programming language with monitors to which multiple inheritance (a la traits ) were added. Used in the implementation of the Xerox Star workstation. [Curr82 Gesc77 Mitc79 Lamp80] ModPascal: An object oriented Pascal. From the University of Kaiserslautern, Germany. Olth86] Oaklisp: Another object oriented lisp with message passing and inheritance. From CarnegieMellon. Lang86] OOCL: An Object Oriented Command Language. Snod83] Objective C: Descendent of OOPC, an ....

B.W. Lampson and D.D. Redell, "Experience with Processes and Monitors in Mesa", CACM, vol. 23, no. 2, pp. 105-117, Feb 1980.

....enables both nonblocking memory management and the sleep wakeup based user mode lock implementation of Section 3.3.3.2. 3.3. 4 Strength of the wait free locking As long as critical sections do not nest, it is easy to see that my construction can be used to implement wait and notify monitors [LR80] or their recent descendant, Java synchronized methods) Whenever a monitor protected object s method is called, the object s lock is acquired. The monitor s wait operation would then be implemented as an unlock sleep lock sequence. Figure 3.5 shows a possible monitor implementation that uses ....

....in more detail in Section 4.2.3. There is a large variety of monitors with differing semantics, but most of them can be shown to have equivalent expressive power [How76, BF95] Wait and notify monitors, also classified as no priority nonblocking monitors [BF95] have first been used in Mesa [LR80] A different situation arises if the locks a critical section needs are known before the critical section starts, and during its execution. In this case, the wait operation can release all locks before sleeping, and reacquire them afterwards. However, this method cannot maintain internal state ....

B. W. Lampson and D. D. Redell. Experience with processes and monitors in Mesa. Communications of the ACM, 23(2):105--117, February 1980.

....Synchronization in Mercury subsumes communication since Mercury threads communicate using shared memory. Mercury has a rich set of synchronization constructs that the programmer can choose from, including spinning and blocking locks, a simple kind of Mesa semantics monitors with condition queues [Lampson and Redell, 1980] and blocking and spinning barriers. Spinlocks Spinlocks are the most basic form of non relinquishing synchronization available in the Mercury runtime. Spinlocks can be constructed, locked, unlocked, conditionally locked and queried for their value. The following example demonstrates the use of ....

B. W. Lampson and D. D. Redell, "Experiences with Processes and Monitors in Mesa," Comraunicalions oflhe ACM, pages 104-117, 1980. 18

....may be a process of medium priority which becomes ready at an instant that the high priority process is blocked by the low priority process. As a consequence the higher priority job is implicitly postponed for an undesirable amount of time. This situation first described by Lampson and Redell [7] was later named the priority inversion problem. Priority inversion leads to unbounded WCETs of high priority processes. Predictability of WCETs again was established with various protocols e.g. priority inheritance protocol (PIP) and priority ceiling protocol (PCP) 11] stack resource policy ....

B. W. Lampson and D. D. Redell. Experiences with processes and monitors in mesa. Communications of the ACM, 23(2):105--117, February 1980.

....by concepts from object oriented programming) in which each thread is structured as a sequence of atomic operations on objects. The result is a more structured, tractable programming model. The advantages of this model have led to its adoption in programming languages such as Mesa and Java [18, 1]. The research presented in this paper attacks a performance problem, synchronization bottlenecks, that arises in the context of multithreaded programs that perform atomic operations on objects. Synchronization bottlenecks occur when multiple threads attempt to concurrently update the same ....

....to make the updates execute atomically serializes the execution of the threads performing the updates. This serialization can harm the performance by limiting the amount of concurrency available in the program. It can also lead to systemlevel anomalies such as lock convoys and priority inversions [18, 29]. In many programs it is possible to eliminate synchronization bottlenecks by replicating frequently accessed objects that cause synchronization bottlenecks. Each thread that updates such an object creates its own local replica and performs all updates locally on that replica with no ....

Butler W. Lampson and David D. Redell. Experience with processes and monitors in Mesa. Communications of the ACM, 23(2):105--117, February 1980.

....execute. Even though traditional compilers have not exploited commuting operations, these operations play an important role in other areas of parallel computing. Explicitly parallel programs, for example, often use locks, monitors, and critical regions to ensure that operations execute atomically [Lampson and Redell 1980]. For the program to execute correctly, the programmer must ensure that all of the atomic operations commute. Four of the six parallel applications in the SPLASH benchmark suite [Singh et al. 1992] and three of the four parallel applications in the SAM benchmark suite [Scales and Lam 1994] rely on ....

LAMPSON, B. W. AND REDELL, D. D. 1980. Experience with processes and monitors in Mesa. Communications of the ACM 23, 2 (February), 105--117.

....program. Then an instance of the virtual machine is instantiated (literally, the daemon forks and the child process runs the virtual machine) and the code within the packet is executed. 5. 1 Virtual Machine Issues There are many ways to implement virtual machines [Lindholm and Yellin 1997; Lampson and Redell 1980; Redell et al. 1980] The critical issues tend to be the richness of the virtual machines s feature set and security. These features tend to dictate the expense and complexity of the virtual machine implementation. In the Smart Packets system, security was vital but the required feature set was ....

Lampson, B. and Redell, D. 1980. Experience with processes and monitors in mesa.

No context found.

B. Lampson and D. Redell. Experience with Processes and Monitors in Mesa. Communications of the ACM, pages 105--117, February 1980.

No context found.

B. W. Lampson and D. D. Redell. Experience with processes and monitors in Mesa. Communications of the ACM, 23(2), February 1980.

No context found.

B. W. Lampson and D. D. Redell. Experience with processes and monitors in mesa. Communications of the ACM, 23(2):105--117, feb 1900.

No context found.

B. W. Lampson and D. D. Redell. Experiences with processes and monitors in mesa. Communications of the ACM, February 1980.

No context found.

B. Lampson and D. Redell. Experience with Processes and Monitors in Mesa. Communications of the ACM, pages 105--117, February 1980.

No context found.

Butler W. Lampson and David D. Redell. Experience with Processes and Monitors in Mesa. Communications of the ACM, 23(2):105--117, February 1980.

No context found.

B. W. Lampson and D. D. Redell. Experience with processes and monitors in mesa. Commun. ACM, 23(2):105--116, Feb. 1980.

No context found.

Butler W. Lampson and David D. Redell. Experience with processes and monitors in Mesa. Communications of the ACM, 23(2):105--117, February 1980.

No context found.

B.W. Lampson, and D.D. Redell. "Experience with Processes and Monitors in Mesa". Communications of the ACM 23, 2, February 1980, pp. 105-107.

No context found.

Butler W. Lampson and David D. Redell. Experiences with processes and monitors in Mesa. Communications of the ACM, 23(2):105--117, February 1980. 131.

No context found.

B. W. Lampson and D. D. Redell. Experience with processes and monitors in mesa. Commun. ACM, 23(2):105-116, Feb. 1980.

First 50 documents  Next 50

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