Name of locking design pattern (the one with `internal' methods)

I recall a design pattern for handling locking issues in C++ (where some locks are not re开发者_如何学Go-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?

It's called Thread-Safe Interface.

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.

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.