The proposed Boost.Xint does not fulfill the thread-safety promises that it makes. The library uses a custom allocator (allocator_t), which uses global variables and does not protect them with a synchronization primitive. There appears to be no way to override the use of this custom allocator (the library just passes the user-specified STL allocator to allocator_t, and allocator_t uses the STL allocator to get memory). Can the author of this library please make the custom allocation strategy optional? Merely making allocator_t threadsafe wouldn't be a solution for me unless I could change the synchronization primitive that this allocator uses. I am using this library within a parallel C++ runtime that implements (among other things) a user-threading layer, so I would want to use one of our synchronization primitives, as OS-level (e.g. Boost.Thread) based synchronization would interfere with our user threading subsystem. I think the better solution here is to not tie Boost.Xint to a particular memory allocation scheme. The allocator in question is in <boost/xint/detail/policies.hpp> -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project