4 ms·

How does OO have any effect on concurrency? I'm genuinely curious here.

barrkel 16y ago
Mutable state. OO prioritizes encapsulation ahead of immutability as a way of making the problem of a mutable struct tractable. Most OO programs are graphs (picture as a complex web) of mutable objects holding references to one another, synchronously passing control from one object's method to the next (picture as a spider travelling around the web, making modifications). Concurrency means there is more than one logical point of control flowing around the graph, making modifications. To ensure modifications are consistent, one must now fight against the interconnected nature of this graph, and make certain areas mutually exclusive; that means you need to set up gates on all the edges leading into those areas (often called semaphores or mutexes). But OO gives you precious little help in setting aside these areas, and guaranteeing internal consistency in the face of multiple mutating points of control. Programs in a functional style are different, with their heavy emphasis on immutability. In this case, the web, as it were, is fixed and cannot be changed; instead, if there is to be a modification, a new copy is created (possibly only of the local area of change, and the unchanged portion included via references). Since there is no way to change data, there can be as many points of control performing operations as desired. (Actually, one of the models of computation used for functional programs is that of graph reduction, which pictures the program as a web of expressions rather than structures; and that big expression is iteratively made smaller by calculating different parts of it. In principle, the more points of control you have doing these calculations, or reductions (in the same way as '1 + 2' can be reduced to '3'), the better.) Programs written in an agent / actor style are also different. Here, there is no single point of control flowing from one node in the graph (web) to the next; instead, each node has its own little point of control, and it reacts to messages coming in from each edge, and sends out messages along edges in response. This makes the program locally single-threaded, but globally concurrent.
- georgieporgie 16y ago
  Code organization aside, how is OO any different from procedural programming with regards to concurrency?
  - barrkel 16y ago
    I would say that procedural code is less inclined towards both immutability and encapsulation than OO; I would say to a first order approximation that it tends to be worse than OO for concurrency. But there are moderating factors. Procedural programs that don't enforce strict modularity conventions tend to be bound in size by their complexity, a complexity that works against the level of understanding necessary to make things both concurrent and correct. Meanwhile, procedural programs that do enforce strict modularity will probably be using conventions that emulate a different paradigm, and will inherit that paradigms' costs and benefits WRT concurrency.
- dkersten 16y ago
  You said it better than I could have! :)
- deleted 16y ago
  [deleted]
nicolaus 16y ago
In 15 years of experience where Java sadly pays the bills, for example, systems written in that language that had a modeling approach that tended toward immutability and tended to limit the visibility of mutable state throughout the system were also more understandable, more amenable to change and therefore better than those that weren't. Irrespective of concurrency and parallelism!
- eru 16y ago
  Yes. Arguing that immutability is possible in Java, is a bit like arguing for good code in PHP. It's possible and advisable. But Java naturally tends towards mutability. And you will have to work harder to make it immutable. Java also does not give you as many tools for this kind of style as functional languages usually give you. First class functions, a rich type system and a library full of immutable data types come to my mind.
  - dkersten 16y ago
    Also OOP (as seen in C++ and Java; the original ideas of passing messages to objects sounds like it would have suited concurrency a lot better) encourages mutable state. Sure, you can program with immutable state (and many people do - I certainly do), but it feels like its going somewhat against the grain of OOP in those languages. Worse, OOP tends to hide the mutable state away internally in objects (or in objects stored inside objects etc) - OOP's data hiding and abstraction support can go against you here. Sure, good programming practices and discipline (eg, const correctness in C++) helps, but the languages definitely encourage mutable state. I wonder how using methods-as-messages and turning OOP into a message passing system not dissimilar to the actor model would work in practice (both from a usability/syntax and concurrency view).

Mutable state. OO prioritizes encapsulation ahead of immutability as a way of making the problem of a mutable struct tractable. Most OO programs are graphs (picture as a complex web) of mutable objects holding references to one another, synchronously passing control from one object's method to the next (picture as a spider travelling around the web, making modifications). Concurrency means there is more than one logical point of control flowing around the graph, making modifications. To ensure modifications are consistent, one must now fight against the interconnected nature of this graph, and make certain areas mutually exclusive; that means you need to set up gates on all the edges leading into those areas (often called semaphores or mutexes). But OO gives you precious little help in setting aside these areas, and guaranteeing internal consistency in the face of multiple mutating points of control. Programs in a functional style are different, with their heavy emphasis on immutability. In this case, the web, as it were, is fixed and cannot be changed; instead, if there is to be a modification, a new copy is created (possibly only of the local area of change, and the unchanged portion included via references). Since there is no way to change data, there can be as many points of control performing operations as desired. (Actually, one of the models of computation used for functional programs is that of graph reduction, which pictures the program as a web of expressions rather than structures; and that big expression is iteratively made smaller by calculating different parts of it. In principle, the more points of control you have doing these calculations, or reductions (in the same way as '1 + 2' can be reduced to '3'), the better.) Programs written in an agent / actor style are also different. Here, there is no single point of control flowing from one node in the graph (web) to the next; instead, each node has its own little point of control, and it reacts to messages coming in from each edge, and sends out messages along edges in response. This makes the program locally single-threaded, but globally concurrent.

georgieporgie 16y ago
Code organization aside, how is OO any different from procedural programming with regards to concurrency?
- barrkel 16y ago
  I would say that procedural code is less inclined towards both immutability and encapsulation than OO; I would say to a first order approximation that it tends to be worse than OO for concurrency. But there are moderating factors. Procedural programs that don't enforce strict modularity conventions tend to be bound in size by their complexity, a complexity that works against the level of understanding necessary to make things both concurrent and correct. Meanwhile, procedural programs that do enforce strict modularity will probably be using conventions that emulate a different paradigm, and will inherit that paradigms' costs and benefits WRT concurrency.
dkersten 16y ago
You said it better than I could have! :)
deleted 16y ago
[deleted]

nicolaus 16y ago

In 15 years of experience where Java sadly pays the bills, for example, systems written in that language that had a modeling approach that tended toward immutability and tended to limit the visibility of mutable state throughout the system were also more understandable, more amenable to change and therefore better than those that weren't. Irrespective of concurrency and parallelism!

eru 16y ago
Yes. Arguing that immutability is possible in Java, is a bit like arguing for good code in PHP. It's possible and advisable. But Java naturally tends towards mutability. And you will have to work harder to make it immutable. Java also does not give you as many tools for this kind of style as functional languages usually give you. First class functions, a rich type system and a library full of immutable data types come to my mind.
- dkersten 16y ago
  Also OOP (as seen in C++ and Java; the original ideas of passing messages to objects sounds like it would have suited concurrency a lot better) encourages mutable state. Sure, you can program with immutable state (and many people do - I certainly do), but it feels like its going somewhat against the grain of OOP in those languages. Worse, OOP tends to hide the mutable state away internally in objects (or in objects stored inside objects etc) - OOP's data hiding and abstraction support can go against you here. Sure, good programming practices and discipline (eg, const correctness in C++) helps, but the languages definitely encourage mutable state. I wonder how using methods-as-messages and turning OOP into a message passing system not dissimilar to the actor model would work in practice (both from a usability/syntax and concurrency view).