Flexible Exclusion Control for Composite Objects Abdelsalam Shanneb John Potter School of Computer Science and Engineering School of Computer Science and Engineering The University of New South Wales The University of New South Wales Sydney – Australia Sydney – Australia shanneba@cse.unsw.edu.au potter@cse.unsw.edu.au Abstract We present a simple approach for implementing flexible locking strategies in a system of components, which may themselves be composite objects. The approach is flexible in that a developer can defer the distribution of locks in the system until deployment: the choice of lock type and granularity may therefore depend on the operating environment. We only consider exclusion control; this includes mutexes, read-write locks and read-write sets, but does not cover state-dependent locking or transaction- based approaches. In general we express exclusion requirements as sets of conflict pairs on component         have demonstrated the effectiveness of a general-purpose exclusion lock that can provide any required exclusion. We presume knowledge of the dependency between the interface of a composite object and its internal components. This work extends and simplifies the work on exclusion algebra for composite objects (Noble, Holmes and Potter         the control required internally and that provided externally. This clarifies the role of the so-called upward and downward mappings of the earlier work. We also offer a succinct mathematical basis for our model. Keywords: Concurrency control, concurrent objects, composite objects, component-based systems, locking granularity  Introduction As programmers, we are imbued with a mind-set attuned to a sequential model of program behaviour. On seeing a sequence of code statements, we naturally think of the effect of this code executing one step after another. Often the correctness of code depends on this sequentiality. When producing code that will operate in a multithreaded environment in which there are concurrent threads operating on a shared memory space, we need to prevent Copyright  ! " #$ % & ’ paper appeared at the  th Australasian Computer Science   The University of Newcastle, Australia. Conferences in Research and Practice in Information ’% ( )* ( +,-Castro, Ed. Reproduction for academic, not-for profit purposes permitted provided this text is included. interference between concurrent threads potentially operating on the same data, that is, we need to guarantee thread-safety for our system. In order to provide thread-safety for software components, the simplest approach is to force mutually exclusive access to the component interface. For example, in Java, we can declare the methods of a class to be synchronized, which has the effect of blocking calls on an instance of that class, whenever another thread has an active method call on the same object. The apartment model of COM also provides this ability to force a whole component to be singly threaded. However forcing single threadedness at a high-level may unnecessarily limit concurrent activity, which then restricts system responsiveness or efficiency in a multiprocessor environment. To increase the potential for concurrent activity, we can adopt two approaches. First we can move the controls inside the components, so that they are closer to the critical sections of code where the sharing violations may occur. Second we can adopt a finer degree of control by enforcing pair-wise exclusion on conflicting method calls, such as with read-write controls. In this paper we only consider exclusion control; this includes mutexes, read-write locks and read-write sets, but does not cover state-dependent locking or transaction-based approaches. This second choice also presumes some knowledge of the internal implementation of the component: we need to know the conflicts between the different methods of the interface. We can of course adopt both of these approaches simultaneously, and provide finer grain locking internally rather than at the external interface. The contribution in this paper is to provide a simple approach to reasoning about the degree of exclusion control required by a particular component when placed in a particular operating environment in which the potential for concurrent calls on the component is known. Components may provide their own locks at their interface. This reduces the internal concurrency potential for the component. We presume knowledge of the dependency relation between a composite object and its internal components. With this knowledge, and given a particular locking strategy for all the components, we show how to propagate internal exclusion requirements outward, and the potential for concurrency inward, thereby checking that all components have been provided with their required exclusion control. This work derives from earlier work by Noble, Holmes    on exclusion for composite objects.