Concurrency Issues Are Orthogonal To Objects

I don't see how concurrency can be orthogonal to objects. Locking in an object-oriented language should be object-based, just as locking in a relational database is typically row-based. When you refactor a class into two classes, or combine two classes into one, you typically change the amount of concurrency you can get. Anyone doing refactoring in a multithreaded application needs to think about how it affects concurrency.

There are more sophisticated locking strategies where you lock only part of an object, but even then you typically rely on synchronization inside your object's methods. Object-oriented design is used to hide a class's implementation of concurrency from the rest of the application.

Furthermore, even in more sophisticated locking strategies (from DougLea's book for example) are typically implemented by creating new objects like queues, consumers, producers, and so on. The way we hide the tricky implementation details of concurrency strategies is by creating new objects.

-- BrianSlesinsky

Good point. The title of this page is sloppy. It should read ConcurrencyIssuesAreOrthogonalToEncapsulation. Perhaps ConcurrencyIssuesAreOrthogonalToObjectIdentity? too, but I think that is a little murkier.