We currently use full barriers before launching a thread and after joining one. The comments say that this is because the APIs don't guarantee them and we want the new thread to be able to see all writes from before its creation, and the joiner thread to see all writes from the joinee. While the comments are correct that the synchronization guarantees are unclear in the platform-specific thread functions (a general problem in those APIs), the C++ spec makes it very explicit for both create, and join. I checked the C++ stdlib implementations and they are using the same functions we are without any fencing, so we are fine. And from a rational level, basically nothing would work without that synchronization.

Note that those functions only provide acquire/release semantics not full barriers, so code like the following can't rely on all memory accesses in a() being strongly ordered with accesses in b(), although it would be very unusual for code to rely on that, so it should be made explicit if it is.

a();
__wt_thread_create(...);
b();