While you waiting my recomendation is very simple: wrap Boost.Test test tools access using your own locks available.
Thanks for the suggestions and taking the requests, Gennadiy ... I was thinking about this (wrapping with my own locks) after finding out the thread-unsafeness, with the only caveat that it does significantly affect the thread timing, which can mask any underlying problems I'm trying to find. I realize that if you add underlying mutex locks into Boost.Test, you're doing some of the same thing yourself ... the biggest difference is that you know which portions need the locks, and which are already thread-safe and don't need additional locks (of course I can always read the Boost.Test code and do the analysis myself, but at that point I'd just as soon volunteer my time to help you with that work. :) ). Any real multi-threading experts are welcome to abuse my assumptions and approaches - I've realized over the last year or two how complex the subject is, and how much I don't yet know ... :) (On a side note, we're using ACE Threads, not Boost Threads, primarily for the specific platform support that ACE Threads provides - Solaris, Vxworks, Win32, Linux, etc.) Cliff