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.''