CSP for Java: Multithreading for all
Gespeichert in:
| Titel: | CSP for Java: Multithreading for all |
|---|---|
| Autoren: | Welch, Peter H., Hilderink, Gerald H., Bakkers, A.W.P., Stiles, Gardiner S. |
| Weitere Verfasser: | Cook, Barry M. |
| Verlagsinformationen: | IOS Press |
| Publikationsjahr: | 1999 |
| Bestand: | University of Kent: KAR - Kent Academic Repository |
| Schlagwörter: | QA 76 Software, computer programming |
| Beschreibung: | Many internet, real-time and embedded applications are most naturally designed using concurrency. Unfortunately, the design of concurrent (multithreaded) programs has the reputation of being extremely difficult and dangerous, due to the possibility of deadlock, livelock, race hazards, or starvation - phenomena not encountered in single-threaded programs. Lea [1] emphasizes concern for the apparent difficulty: "Liveness considerations in concurrent software development introduce context dependencies that can make the construction of reusable components harder than in strictly sequential settings." Two approaches he suggests for design sound tedious and perhaps risky: "Top-down (safety first): Initially design methods and classes assuming full synchronization (when applicable), and then remove unnecessary synchronization as needed to obtain liveness and efficiency.Bottom up (liveness first): Initially design methods and classes without concern for synchronization policies, then add them via composites, subclassing, and related layering techniques." Both suggest lengthy sessions of patching and testing until the application appears to work as desired. Even those intimately connected with Java seem reluctant to employ more than a single thread. The Swing documentation states "If you can get away with it, avoid using threads. Threads can be difficult to use, and they make programs harder to debug. In general, they just aren\'t necessary for strictly GUI work, such as updating component properties" [2]. Oaks and Wong [3], also associated with Sun, are more positive, but note that "Deadlock between threads competing for the same set of locks is the hardest problem to solve in any threaded program. It\'s a hard enough problem, in fact, that we will not solve it or even attempt to solve it." Later they state "Nonetheless, a close examination of the source code is the only option presently available to determine if deadlock is a possibility." and add that no tools exist for detecting deadlock in Java programs. We feel, ... |
| Publikationsart: | book part |
| Sprache: | unknown |
| Relation: | Welch, Peter H. and Hilderink, Gerald H. and Bakkers, A.W.P. and Stiles, Gardiner S. (1999) CSP for Java: Multithreading for all. In: Cook, Barry M., ed. Proceedings of WoTUG-22: Architectures, Languages and Techniques for Concurrent Systems. Concurrent Systems Engineering . IOS Press, Amsterdam, Netherlands, pp. 277-278. ISBN 90-5199-480-X. (The full text of this publication is not currently available from this repository. You may be able to access a copy if URLs are provided) (KAR id:16746 ) |
| Verfügbarkeit: | https://kar.kent.ac.uk/16746/ http://www.wotug.org/paperdb/show_pap.php?f=1&num=350 |
| Dokumentencode: | edsbas.722D3B26 |
| Datenbank: | BASE |
Nájsť tento článok vo Web of Science | Abstract: | Many internet, real-time and embedded applications are most naturally designed using concurrency. Unfortunately, the design of concurrent (multithreaded) programs has the reputation of being extremely difficult and dangerous, due to the possibility of deadlock, livelock, race hazards, or starvation - phenomena not encountered in single-threaded programs. Lea [1] emphasizes concern for the apparent difficulty: "Liveness considerations in concurrent software development introduce context dependencies that can make the construction of reusable components harder than in strictly sequential settings." Two approaches he suggests for design sound tedious and perhaps risky: "Top-down (safety first): Initially design methods and classes assuming full synchronization (when applicable), and then remove unnecessary synchronization as needed to obtain liveness and efficiency.Bottom up (liveness first): Initially design methods and classes without concern for synchronization policies, then add them via composites, subclassing, and related layering techniques." Both suggest lengthy sessions of patching and testing until the application appears to work as desired. Even those intimately connected with Java seem reluctant to employ more than a single thread. The Swing documentation states "If you can get away with it, avoid using threads. Threads can be difficult to use, and they make programs harder to debug. In general, they just aren\'t necessary for strictly GUI work, such as updating component properties" [2]. Oaks and Wong [3], also associated with Sun, are more positive, but note that "Deadlock between threads competing for the same set of locks is the hardest problem to solve in any threaded program. It\'s a hard enough problem, in fact, that we will not solve it or even attempt to solve it." Later they state "Nonetheless, a close examination of the source code is the only option presently available to determine if deadlock is a possibility." and add that no tools exist for detecting deadlock in Java programs. We feel, ... |
|---|