I recall a design pattern for handling locking issues in C++ (where some locks are not re-entrant) by separating methods into 'external' and 'internal' ones. External ones acquire locks and can call internal ones which in turn assert that locks are held. External ones cannot call other external ones (because that would deadlock) and for the same reason, internal ones cannot call external ones. Does anybody remember the name of this pattern?
+1
A:
I don't think that's really a design pattern - to me it's an implementation practice intended to prevent deadlocks, and detect them in the case of misuse of the class.
EDIT: However, Douglas Schmidt disagrees so I guess it IS a pattern.
Steve Townsend
2010-09-21 18:38:38
Yet, it does have a name and I distinctly remember reading about it in a design pattern book ...
Lajos Nagy
2010-09-21 18:43:59
A:
This pattern is applicable not only to locks and threads, but to many other situations where an API must "set something up", do something with it, and then take it down. Historical examples include API's that switched to their own stack, or graphical hardware systems which would be banked-switched into memory, manipulated, and banked out.
supercat
2010-09-21 19:07:00