An ideal, if not the best, synchronization mechanism for a concurrent software reuse library, based on our experience, is a declarative mechanism. Synchronization primitives for a class should be placed in a predefined segment (or section) so that it is easy to modify them for reuse. Thus, we use an object-level synchronization mechanism in COORL. For example, see the Control segments in Figure 2 (ignore the syntax for the time being). Of course, when a declarative synchronization mechanism is used, the primitives will inevitably lose some flexibility compared with the traditional synchronization mechanisms, such as semaphore, fork, etc. But overall, reusability increases, especially in our model when an abstract class is the basic reuse unit.
There exist many declarative mechanisms for concurrent object-oriented languages but many of them have the same basic constructs, i.e. synchronization counters, such as req(op), wait(op), start(op), exec(op), etc., where ``op'' represents an invocation of a method. These kinds of primitives can be found in Guide [#!Decouchant89!#], DRAGOON [#!Atkinson91!#], and Scheduling Predicates [#!McHale91!#], etc.
In COORL, we can synthesize those synchronization counters once a subclass has been defined. As long as the counters are consistent, our primitives can be used to manipulate them and, at the same time, to avoid the conflict between the synchronization and inheritance. In order to enhance the expressive power for a declarative synchronization mechanism, we merge two other constructs, namely the atomic block and transaction concepts [#!Kaiser90!#], in the current version of COORL.