J. Ousterhout, "Why threads are a bad idea (for most purposes)," 1996. Invited talk given at USENIX Technical Conference, available at http://www.scriptics.com/people/john.ousterhout/threads.ps.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....While the experiments were successful, significant scheduling trade offs remain unsolved. For instance, it is not clear under which circumstances a policy should delay a request before the locality benefit disappears. Thread scalability is limited when building highly concurrent applications [Ous96][PDZ99] Related work suggests inexpensive implementations for context switching [AB 91] BM98] and also proposes event driven architectures with limited thread usage, mainly for internet services [PDZ99] Welsh et al. propose a staged event driven architecture (SEDA) for deploying highly ....

....their trade offs and challenges are further discussed over the next paragraphs. 3.1. 1 Choosing the right thread pool size Although multithreading is an efficient way to mask I O and network latencies and fully exploit multiprocessor platforms, many researchers argue against thread scalability [Ous96][PDZ99] WCB01] Related studies suggest (a) maintaining a thread pool that continuously picks clients from the network queue to avoid the cost of creating a thread per client arrival, and (b) adjusting the pool size to avoid an unnecessarily large number of threads. Modern commercial DBMS ....

J. K. Ousterhout. "Why threads are a bad idea (for most purposes)." Invited talk at 1996 USENIX Tech. Conf. (slides available at http://home.pacbell.net/ouster/), Jan. 1996.

....to avoid constraining the order of initialization for thread specific storage keys. 12 Concluding Remarks Multi threading an existing application often adds significant complexity to the software due to the additional concurrency control protocols needed to prevent race conditions and deadlocks [11]. The Thread Specific Storage pattern alleviates some of synchronization overhead and programming complexity by allowing multiple threads to use one logically global access point to retrieve thread specific data without incurring locking costs for each access. Application threads use TS Object ....

J. Ousterhout, "Why Threads Are A Bad Idea (for most purposes)," in USENIX Winter Technical Conference,(San Diego, CA), USENIX, Jan. 1996.

....CORBA middleware to meet the requirements of real time applications. This section outlines related work on concurrency and demultiplexing and compares it with the techniques applied in TAO. There is a striking similarity between the TAO concurrency model and that recommended by Ousterhout [38]. To avoid the difficulties of threading at the application level, Ousterhout recommends an event driven model for most applications. But for performance critical kernel code, Ousterhout recommends 5 The IDL Compiler row refers to the code required to collaborate between the IDL compiler and the ....

J. Ousterhout, "Why Threads Are A Bad Idea (for most purposes)," in USENIX Winter Technical Conference, (San Diego, CA), USENIX, Jan. 1996.

....CORBA middleware to meet the requirements of real time applications. This section outlines related work on concurrency and demultiplexing and compares it with the techniques applied in TAO. There is a striking similarity between the TAO concurrency model and that recommended by Ousterhout [35]. To avoid the difficulties of threading at the application level, Ousterhout recommends an event driven model for most applications. But for performance critical kernel code, Ousterhout recommends that threads be used in the kernel. If the TAO ORB Core and Object Adapter are viewed as the ....

J. Ousterhout, "Why Threads Are A Bad Idea (for most purposes) ," in USENIX Winter Technical Conference, (San Diego, CA), USENIX, Jan. 1996.

....from the implementation of thread specific storage provided by OS thread libraries. 12 Concluding Remarks Multi threading an existing application often adds significant complexity to the software due to the additional concurrency control protocols needed to prevent race conditions and deadlocks [11]. The Thread Specific Storage pattern alleviates some of synchronization overhead and programming complexity by allowing multiple threads to use one logically global access point to retrieve thread specific data without incurring locking costs for each access. Application threads use TS Object ....

J. Ousterhout, "Why Threads Are A Bad Idea (for most purposes) ," in USENIXWinter TechnicalConference,(San Diego, CA), USENIX, Jan. 1996.

....to avoid constraining the order of initialization for thread specific storage keys. 12 Concluding Remarks Multi threading an existing application often adds significant complexity to the software due to the additional concurrency control protocols needed to prevent race conditions and deadlocks [11]. The Thread Specific Storage pattern alleviates some of synchronization overhead and programming complexity by allowing multiple threads to use one logically global access point to retrieve thread specific data without incurring locking costs for each access. Application threads use TS Object ....

J. Ousterhout, "Why Threads Are A Bad Idea (for most purposes)," in USENIX Winter Technical Conference, (San Diego, CA), USENIX, Jan. 1996.

.... applications often perform no better, or even worse, than single threaded applications due to the overhead of acquiring and releasing locks [1] In addition, threads are hard to program correctly due to subtle concurrency control protocols (e.g. avoiding race conditions and deadlock)[2]. This paper describes the Thread Specific Storage pattern, which helps to alleviate several problems with thread performance and complexity. The Thread Specific Storage pattern improves performance and simplifies multi threaded applications by allowing multiple threads to use one logical access ....

J. Ousterhout, "Why Threads Are A Bad Idea (for most purposes) ," in USENIX Winter Technical Conference, (San Diego, CA), USENIX, Jan. 1996.

....where low level external events, such as I O, are most efficiently managed asynchronously, but higher level functionality is most conveniently processed as synchronously. An alternative approach uses threads in the lower layers of an application architecture and events in higher layers [44]. Threading in the lower layers effectively supports true concurrency, such as when multiple CPUs or I O channels are available. The event driven upper levels insulate application level programmers from the disadvantages of threads, i.e. deadlock and locking of shared data. This approach is ....

....between event driven and multithreaded approaches do not indicate a clear preference, in general. Hybrid approaches can take advantage of each one s strengths while minimizing its weaknesses. 7 Related Work There is a striking similarity between the TAO model and that recommended by Ousterhout [44]. To avoid the difficulties, discussed in Section 6, of threading at the application level, Ousterhout recommends an event driven model for most applications. But for performance critical kernel code, Ousterhout recommends that threads may be used in the kernel. If the TAO layers from the Object ....

J. Ousterhout, "Why Threads Are A Bad Idea (for most purposes) ," in USENIX Winter Technical Conference, (San Diego, CA), USENIX, Jan. 1996.

No context found.

J. Ousterhout, "Why threads are a bad idea (for most purposes)," 1996. Invited talk given at USENIX Technical Conference, available at http://www.scriptics.com/people/john.ousterhout/threads.ps.

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