3 ms·

Not OP, but that might be an implication. Another, more general reason is that this kind of concurrency requires design. It can’t be thought of as a defensive p

by dgb23 4y ago

Not OP, but that might be an implication. Another, more general reason is that this kind of concurrency requires design. It can’t be thought of as a defensive programming technique. Locks are too powerful and they are by definition a point of contention. I think providing a lock is like giving up control to someone else. It’s inherent coupling. To contrast, when I first learned about them I thought of them as a protection mechanism of an isolated part, but they are an execution contract that everyone participates in.

jerf 4y ago
"It’s inherent coupling." This matches well with one of the beliefs I've been polishing up over the past few years which I don't think is well understood, which is that structured programming tends to create more coupling than we realize in deep call stacks. When you end up with a 2000-line call stack in Java, that's 2000 function invocations coupled together by the way structured programming works; for instance, at a bare minimum, that's 1999 functions that can't progress until the innermost one does, and that's not the only form of coupling. I think the coupling induced by structured programming is fairly light per stack frame on average, but they tend to add up quickly because they're just so darned easy to add more of. Locks are another thing that makes this really come to light. The more stack frames between some function and something above it in the stack that has taken a lock, the more likely it is for execution to eventually wander back into something trying to take a lock inadvisably. I mean, I've had a number of deadlocks just within an object where it has some internal lock, and a method takes that lock, then tries to call a method that takes the same lock. Whoops. Easy to fix, of course, but that's the easy case. The cases get harder in real code.
- dgb23 4y ago
  So the stack is a 'lie'? Or the 'wrong' data structure? It isn't just caller knows about callee, there's cross frame and cross stack coupling going on. There is something interesting in your idea.
  - jerf 4y ago
    I don't think it's a lie. It's very, very useful. It did not survive as long as it did without providing value. It killed its competition stone dead for a reason. I just think we underestimate the coupling it introduces. Doesn't mean the solution is to throw it all out. I'm not even sure there is "a solution". Just something to keep in mind.

by dgb23 4y ago

jerf 4y ago

"It’s inherent coupling." This matches well with one of the beliefs I've been polishing up over the past few years which I don't think is well understood, which is that structured programming tends to create more coupling than we realize in deep call stacks. When you end up with a 2000-line call stack in Java, that's 2000 function invocations coupled together by the way structured programming works; for instance, at a bare minimum, that's 1999 functions that can't progress until the innermost one does, and that's not the only form of coupling. I think the coupling induced by structured programming is fairly light per stack frame on average, but they tend to add up quickly because they're just so darned easy to add more of. Locks are another thing that makes this really come to light. The more stack frames between some function and something above it in the stack that has taken a lock, the more likely it is for execution to eventually wander back into something trying to take a lock inadvisably. I mean, I've had a number of deadlocks just within an object where it has some internal lock, and a method takes that lock, then tries to call a method that takes the same lock. Whoops. Easy to fix, of course, but that's the easy case. The cases get harder in real code.

dgb23 4y ago
So the stack is a 'lie'? Or the 'wrong' data structure? It isn't just caller knows about callee, there's cross frame and cross stack coupling going on. There is something interesting in your idea.
- jerf 4y ago
  I don't think it's a lie. It's very, very useful. It did not survive as long as it did without providing value. It killed its competition stone dead for a reason. I just think we underestimate the coupling it introduces. Doesn't mean the solution is to throw it all out. I'm not even sure there is "a solution". Just something to keep in mind.