I am really surprised to see everyone agreeing that a header-only implementation is preferable. In my day job we have strict rules about what is allowed to appear in header files, the principal reason being to reduce dependencies between header files in order to keep compile times and code bloat manageable. For example, we prefer forward declaring classes over #includes when possible, we use the pimpl idiom on occasion, we use abstract interfaces in as much code as possible, etc. All of which help to make for a more loosely coupled design which has the benefit of minimising the amount of code that is transitively included in each compilation unit.
As a user of boost, linking in a few libraries is a minor pain that I am willing to take, compared to the pain of long build times.
Violent agreement, Boost.Threads is an excellent candidate to keep implementation and interfaces separate. However, there is a need for a small (possibly *very* small) subset which is header only so that other Boost libs which otherwise need no external linkage can become thread safe without constantly rolling their own solution (something that is a "bad thing" with a capital "B" !). I would guess that one mutex type would do it at a pinch, but call_once and various atomic operations would be a help as well. Regards, John.