E. Markatos, M. Crovella, and P. Das. The effects of multiprogramming on barrier synchronization. In Proceedings of the 3rd IEEE Symposium on Parallel and Distributed Processing, pages 662--669, December 1991.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....of message passing protocols. Since dedicated hardware barrier trees are intrinsically parallel and have very low latency, they are usually an order of magnitude faster than software barriers. There exist numerous algorithms and methods in the literature for improved software barriers, including [1, 7, 10, 13, 14, 12, 20], but these are improvements on a mechanism that is inherently slow. Methods for masking the latency of barriers have also been proposed [5, 6] These methods hide the synchronization overhead as well as the time spent waiting for other processors to reach the barrier. They depend on being able to ....

E. Markatos, M. Crovella, and P. Das. The effects of multiprogramming on barrier synchronization. In Proceedings of the 3rd IEEE Symposium on Parallel and Distributed Processing, pages 662--669, December 1991.

....The problem is related to, but more severe than, the preemption while waiting problem in FIFO locks. With a lock the scheduler may need to cycle through the entire ready list before reaching the process that is able to make progress. With a scalable busy wait barrier, Markatos et al. have shown [28] that the scheduler may need to cycle through the entire ready list a logarithmic number of times (spinning for as long as a quantum between context switches) in order to achieve the barrier. To avoid this problem, they suggest (without an implementation) that blocking synchronization be used ....

....caused by multiprogrammed environments, since they require portions of the barrier code in different processes to be interleaved in a deterministic order. This order may conflict with the scheduling policy on a multiprogrammed system, consequently causing an unreasonable number of context switches [28] to occur before achieving the barrier. The basic idea of our scalable scheduler conscious barrier is to make the optimal spin versus block decision within each individual processor or cluster, and to employ a scalable log depth barrier across processors, where context switches are not an issue. ....

E. Markatos, M. Crovella, P. Das, C. Dubnicki, and T. LeBlanc. The Effects of Multiprogramming on Barrier Synchronization. In Proceedings of the Third IEEE Symposium on Parallel and Distributed Processing, pages 662--669, December 1991.

....of message passing protocols. Since dedicated hardware barrier trees are intrinsically parallel and have very low latency, they are usually an order of magnitude faster than software barriers. There exist numerous algorithms and methods in the literature for improved software barriers, including [1, 5, 7, 11, 12, 10, 17], but these are improvements on a mechanism that is inherently slow. Methods for masking the latency of barriers have also been proposed [3, 4] These methods hide the synchronization overhead as well as the time spent waiting for other processors to reach the barrier. They depend on being able to ....

E. Markatos, M. Crovella, and P. Das. The effects of multiprogramming on barrier synchronization. In Proceedings of the 3rd IEEE Symposium on Parallel and Distributed Processing, pages 662--669, December 1991.

....the last process before any process can continue. In a traditional centralized barrier, the last arriving process discovers that the barrier has been achieved in constant time (ignoring possible delay due to contention) deterministic ordering If processors are multiprogrammed, Markatos et al. [11] have shown that deterministic ordering of process synchronizations can cause an unreasonably large number of context switches. Busy waiting remains an option in the presence of multiprogramming so long as each process will eventually relinquish the processor when the condition for which it is ....

.... combining tree barrier, but block instead of spinning blocking is not possible, but assignment of processes to processors is known and relatively static use centralized barrier within processors and logarithmic barrier (choice is not crucial) between processors, as suggested by Markatos et al. [11] process assignment is dynamic or unknown, and either multiprogramming is not certain to occur or else blocking is not possible use non fuzzy local spinning non adaptive combining tree barrier with breadth first wakeup Figure 21: Summary of recommendations. of fuzzy delays negates the benefits ....

E. Markatos, M. Crovella, P. Das, C. Dubnicki and T. LeBlanc, "The Effects of Multiprogramming on Barrier Synchronization," Proceedings of the Third IEEE Symposium on Parallel and Distributed Processing, December 1991, pp. 662-669.

.... barriers exacerbate the problem by requiring portions of the barrier code in different processes to be interleaved in a deterministic order an order that may conflict with the scheduling policy on a multiprogrammed processor, and that may require an unreasonable number of context switches [10]. We have developed a simple and coherent set of mechanisms to handle synchronization difficulties arising from multiprogramming. The key idea is to share information across the application kernel interface in order to eliminate the sources of overhead mentioned above. Specifically, the kernel ....

....and adjusts dynamically to the available number of processors in an application s partition. Two level barriers employ a single counter on each processor, and a scalable barrier between processors. They were originally proposed by Axelrod [2] to minimize requirements for locks; Markatos et al. [10] first suggested their use to minimize overhead on multiprogrammed systems. The ability to perform well in the presence of multiprogramming is a combination of intelligent algorithms and extensions to the kernel interface. We have extended the kernel interface in three ways: 1. The kernel and ....

E. Markatos, M. Crovella, P. Das, C. Dubnicki, and T. LeBlanc. The Effects of Multiprogramming on Barrier Synchronization. In Proceedings of the Third IEEE Symposium on Parallel and Distributed Processing, pages 662--669, December 1991.

....it was using) but they dismiss this possibility as unreasonably communication intensive on a large scale machine. Our scalable combination barrier tracks the number of processes at the barrier only within each processor or cluster. With a scalable busy wait barrier, Markatos et al. have shown [28] that the scheduler may need to cycle through the entire ready list a logarithmic number of times (with a full quantum s worth of spinning between context switches) in order to achieve the barrier. To avoid this problem, they suggest (withoutan implementation) that blockingsynchronization be used ....

MARKATOS, E., CROVELLA, M., DAS, P., DUBNICKI, C., and LEBLANC, T. The Effects of Multiprogramming on Barrier Synchronization. In Proceedings of the Third IEEE Symposium on Parallel and Distributed Processing, pages 662--669, December 1991.

....Zahorjan et al. 33] discuss how spin times are affected by scheduling policy. One of their results indicates that for the lock accessing workload, the scheduling policy used in this paper (they call it application based blocking policy) provides the best performance. 4 Martkatos et al. [20] have investigated the effect of multiprogramming on barrier synchronization when the scheduling policy partitions the hardware and gives each application a set of dedicated processors. In contrast to the previous studies, they consider the distributed task queue organization. They compare ....

....to be marginal and, therefore, do not substantially change the conclusions derived for this workload. 9. CONCLUSIONS We have considered the trade offs between spinning and blocking in the context of hierarchical and distributed run queue organizations. With the exception of Markatos et al. [20], all previous studies have assumed a centralized task queue organization. In addition, round robin task scheduling policy has been used in the previous studies. In contrast, we use the run tocompletion (with voluntary blocking, if blocking is used) scheduling policy. Previous studies indicate ....

E. Markatos, M. Crovella, P. Das, C. Dubnicki, T. LeBlanc, The effects of multiprogramming on barrier synchronization, in: Proc. IEEE Symp. Parallel and Distributed Processing, (Dallas, 1991) 662-669.

....which application thread to schedule next. Edler et al. have suggested temporarily preventing a thread from being preempted while it is in a critical section. Marsh et al. and Anderson et al. have suggested that preemption information be communicated from the kernel to user space. Markatos et al. [8] have analyzed the suitability of alternative barrier data structures in a multiprogramming environment. They conclude that combination barriers, using blocking synchronization within a node and spinning across nodes, perform the best. Karlin et al. [6] have developed and tested a set of different ....

E. Markatos, M. Crovella, P. Das, C. Dubnicki, and T. LeBlanc. The effects of multiprogramming on barrier synchronization. In Proceedings of the third symposium on parallel and distributed programming, pages 662--669, December 1991.

.... [10] Scalable barriers exacerbate the problem by requiring portions of the barrier code in different processes to be interleaved in a deterministic order an order that may conflict with the scheduling policy on a multiprogrammed processor, leading to an unreasonable number of context switches [14]. We have developed a simple set of mechanisms to handle synchronization difficulties arising from multiprogramming. The key idea is to share information across the application kernel interface in order to eliminate the sources of overhead mentioned above. Specifically, the kernel exports the ....

....and adjusts dynamically to the available number of processors in an application s partition. Two level barriers employ a single counter on each processor, and a scalable barrier between processors. They were originally proposed by Axelrod [3] to minimize requirements for locks; Markatos et al. [14] first suggested their use to minimize overhead on multiprogrammed systems. The ability to perform well in the presence of multiprogramming is a combination of intelligent algorithms and extensions to the kernel interface. We have extended the kernel interface in three ways: 1. The kernel and ....

Evangelos Markatos, Mark Crovella, Prakash Das, Cesary Dubnicki, and Thomas LeBlanc. The Effects of Multiprogramming on Barrier Synchronization. In Proceedings of the Third IEEE Symposium on Parallel and Distributed Processing, pages 662--669, December 1991.

.... [9] Scalable barriers exacerbate the problem by requiring portions of the barrier code in different processes to be interleaved in a deterministic order an order that may conflict with the scheduling policy on a multiprogrammed processor, leading to an unreasonable number of context switches [13]. We have developed a simple set of mechanisms to handle synchronization difficulties arising from multiprogramming. The key idea is to share information across the application kernel interface in order to eliminate the sources of overhead mentioned above. Specifically, the kernel exports the ....

....and adjusts dynamically to the available number of processors in an application s partition. Two level barriers employ a single counter on each processor, and a scalable barrier between processors. They were originally proposed by Axelrod [3] to minimize requirements for locks; Markatos et al. [13] first suggested their use to minimize overhead on multiprogrammed systems. The ability to perform well in the presence of multiprogramming is a combination of intelligent algorithms and extensions to the kernel interface. We have extended the kernel interface in three ways: 1. The kernel and ....

Evangelos Markatos, Mark Crovella, Prakash Das, Cesary Dubnicki, and Thomas LeBlanc. The Effects of Multiprogramming on Barrier Synchronization. In Proceedings of the Third IEEE Symposium on Parallel and Distributed Processing, pages 662--669, December 1991.

....processes takes 550 s, we can expect the sort program to spend almost 18 seconds during execution just to context switch between kernel processes. The Gaussian elimination program has only 512 barriers, but each is a tree barrier, which can introduce context switches for each level in the tree [15]. The performance advantage of user level threads is substantial in these cases, and we would expect many parallel applications to produce comparable results on other systems. To show that these are not pathological examples, particularly with respect to the number of threads in use, we measured ....

E. Markatos, M. Crovella, P. Das, C. Dubnicki and T. J. LeBlanc, "The Effects of Multiprogramming on Barrier Synchronization," TR 380, Computer Science Department, University of Rochester, May 1991.

No context found.

Evangelos Markatos, Mark Crovella, Prakash Das, Cezary Dubnicki, and Tom LeBlanc. The effects of multiprogramming on barrier synchronization. In Proceedings of the 1991 IEEE Symposium on Parallel and Distributed Processing, pages 662--669, 1991.

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