{"content":[{"text":"A QUALITY OF SERVICE DRIVEN CONCURRENCY FRAMEWORK \n FOR OBJECT-BASED MIDDLEWARE","bbox":{"left":0.16549,"top":0.075947,"width":0.669029,"height":0.041452}},{"text":"Geoff Coulson and Oveeyen Moonian \n Distributed Multimedia Research Group, \n Computing Department, \n Lancaster University, \n Lancaster LA1 4YR, \n UK","bbox":{"left":0.354118,"top":0.132501,"width":0.29159700000000005,"height":0.10747599999999999}},{"text":"e-mail: geoff@comp.lancs.ac.uk","bbox":{"left":0.385098,"top":0.26017,"width":0.22983000000000003,"height":0.018595000000000028}},{"text":"ABSTRACT \n Threads play a key role in object-based middleware platforms. Implementers \n of such platforms can select either kernel or user-level threads, but neither of \n these options are ideal. In this paper we introduce Application Scheduler \n Contexts (ASCs) which flexibly combine both types of thread and thereby \n attempt to exploit the advantages of each. Multiple ASCs can co-exist, each \n with their own concurrency semantics and scheduling policy. ASCs also \n support quality of service (QoS) configurability, and define their own QoS \n schema. We show how ASCs can be efficiently implemented and how they can \n usefully be exploited in middleware environments. We also provide a \n quantitative evaluation that demonstrates the feasibility of the ASC concept in \n performance terms. \n 1. Introduction \n Threads play a key role in object-based middleware platforms (also referred to as \n Object Request Brokers or ORBs) such as the OMG’s CORBA [OMG,00] or \n Microsoft’s DCOM [Microsoft,99]. Essentially, threads fulfill three main roles in such \n platforms: First and foremost, they allow objects to execute concurrently with remote \n invocations to (and from) other objects in the same address space (aka capsule). \n Second, they facilitate the structuring of autonomous distributed objects inside a single \n capsule. Third, they allow CPU resources to be selectively targeted at logically \n separate activities in a capsule. For example, separate threads can be dedicated to \n incoming message handling, user interface processing and media stream processing. \n Furthermore, by dedicating varying numbers of threads with varying priorities, \n deadlines etc., to such activities, the quality of service (QoS) of activities can be \n individually managed and controlled. \n There are two types of thread in common use: Kernel threads are implemented and \n scheduled by the operating system (OS). User-level threads, on the other hand, are \n implemented in a user-level library and are transparent to the OS. The user-level library \n allocates stack memory for each thread, and switches threads by saving and restoring \n per-thread CPU state such as the stack pointer and instruction pointer registers. While \n early middleware platforms (e.g. ANSAware [ANSA,91] and DCE [OG,99]) tended to \n incorporate user-level threads, recent platforms are far more likely to employ kernel \n threads. This is partly because kernel threads are now more widely available than","bbox":{"left":0.161176,"top":0.305273,"width":0.678824,"height":0.615651}},{"text":"- 1 -","bbox":{"left":0.497255,"top":0.966773,"width":0.033196,"height":0.020212000000000008}}],"images_bbox":[],"images_bbox_not_text_overlap":[]}