Abstract
Much of today’s software deals with multiple concurrent tasks. Web browsers support multiple concurrent HTTP connections, graphical user interfaces deal with multiple windows and input devices, and Web and DNS servers handle concurrent connections or transactions from large numbers of clients. The number of concurrent tasks that needs to be handled increases while software grows more complex. Structuring concurrent software in a way that meets the increasing scalability requirements while remaining simple, structured, and safe enough to allow mortal programmers to construct ever-more complex systems is a major engineering challenge.
- Fuchs, M. 1996. Escaping the event loop: An alternative control structure for multithreaded GUIs. In Engineering for Human-Computer Interaction, ed. C. Unger and L. J. Bass. Chapman & Hall. Google ScholarDigital Library
- Ousterhout, J. 1996. Why threads are a bad idea (for most purposes). Invited talk at the Usenix Technical Conference.Google Scholar
- Schmidt, D., and Harrison, T. 1996. Double-checked locking: An optimization pattern for efficiently initializing and accessing thread-safe objects. 3rd Pattern Languages of Program Design Conference; http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf. Google ScholarDigital Library
- Meyers, S., and Alexandrescu, A. 2004. C++ and the perils of double-checked locking. Dr. Dobbs Journal (July-August); http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf.Google Scholar
- Adya, A., Howell, J., Theimer, M., Bolosky, W. J., and Douceur, J. R. Cooperative task management without manual stack management, or event-driven programming is not the opposite of threaded programming; http://research.microsoft.com/sn/Farsite/USENIX2002.ps. Google ScholarDigital Library
- State Threads Library for Internet Applications; http://state-threads.sourceforge.net/.Google Scholar
- Stackless Python; http://www.stackless.com/wiki/Stackless.Google Scholar
Index Terms
- Threads without the Pain: Multithreaded programming need not be so angst-ridden.
Recommendations
Transactional Read-Modify-Write Without Aborts
Language-level transactions are said to provide “atomicity,” implying that the order of operations within a transaction should be invisible to concurrent transactions and thus that independent operations within a transaction should be safe to execute in ...
Effects for cooperable and serializable threads
TLDI '10: Proceedings of the 5th ACM SIGPLAN workshop on Types in language design and implementationReasoning about the correctness of multithreaded programs is complicated by the potential for unexpected interference between threads. Previous work on controlling thread interference focused on verifying race freedom and/or atomicity. Unfortunately, ...
Efficient execution of speculative threads and transactions with hardware transactional memory
Thread-level speculation (TLS) was researched to automatically parallelize portions of serial programs for execution, and transactional memory (TM) was studied as a promising alternative of lock for parallel programming due to its simplicity. Both TLS ...
Comments