by Herb Sutter
What’s good for the function and the object is also good for the thread, the task, and the lock
Structured code was naturally localized and bounded so that parts could be reasoned about in isolation, and entire programs became more understandable, predictable, and deterministic. It was also a huge boon to reusability and a direct enabler of reusable software libraries as we know them today, because structured code made it much easier to treat a call tree. he structuredness that let any call tree be designed, debugged, and delivered as a unit has worked so well, and made our code so much easier to write and understand, that we still apply it rigorously today: In every major language, we just expect that “of course” function calls on the same thread should still logically nest by default, and doing anything else is hardly imaginable.
That’s great, but what does it have to do with concurrency?
A Tale of Three Kinds of Lifetimes
In addition to the function lifetimes we’ve just considered, Table 1 shows three more kinds of lifetimes — of objects, of threads or tasks, and of locks or other exclusive resource access — and for each one lists some structured examples, unstructured examples, and the costs of the unstructured mode.
