Hi, I am new to this list, although not completely new to using Boost. When working with mutexes and locks, it is common to have functions which are part of critical sections but do not lock themselves. A typical example for this is the thread safe interface design pattern, which moves all locking to the publicly available interface functions of a class and all implementation to internal functions which expect to be called with a lock in effect. I would feel much more confident if I could check "expect to be called with a lock in effect" in debug builds. That is, if I could test whether a mutex is locked for a specific thread (in my case, "current thread" would suffice). Especially if some functions need locking and others don't and the goal is to minimize locking for performance's sake, pure convention and documentation without runtime checks seems to me dangerously error prone. Is there any way to do this test which I overlooked? Is my desire sensible? Or are there other/better ways to make sure necessary locking is done? Best regards, Kai Brüning -- RagTime GmbH Tel: [49] (2103) 9657-0 Neustraße 69 Fax: [49] (2103) 9657-96 D-40721 Hilden mailto:kai@RagTime.de Deutschland http://www.RagTime.de/