1

While pthread_create provides a memory order guarantee (The Open Group Base Specifications Issue 7: Memory Synchronization), the wording in Synchronization and Multiprocessor Issues: Memory Ordering and the lack of wording in CreateThread function suggests CreateThread does not.

Coder
  • 441
  • 2
  • 17
  • @rcgldr Windows has a memory barrier API that is highly efficient, IF it needs to be used. As the question states, pthread_create does provide a memory order guarantee. I haven't been able to find documentation beyond what I've included in the description that explicitly states one way or the other for CreateThread. Again, the documentation I've found suggests it deviates from pthread_create in this regard. – Coder Jul 31 '15 at 07:31
  • @rcgldr Correct, the memory order guarantee provided by POSIX for pthread_create only relates to memory order of the calling thread, not the one created. – Coder Jul 31 '15 at 07:47
  • @rcgldr The question is in regard to memory order guarantees of the API, not how a memory barrier could be implemented or how to communicate among threads. – Coder Jul 31 '15 at 07:52
  • @rcgldr See http://stackoverflow.com/questions/22347856/pthread-create3-and-memory-synchronization-guarantee-in-smp-architectures – Coder Jul 31 '15 at 07:54
  • @rcgldr "The description does mention that the created thread can start running before CreateThread() returns." -- The same is true of pthread_create, which has a memory order guarantee. – Coder Jul 31 '15 at 08:05
  • Since it isn't specified, I would just assume that CreateThread() does not provide a memory barrier. One of the passed parameters is a pointer to a variable, but I'm not sure if there's a memory barrier for the actual variable (which could be a structure). – rcgldr Jul 31 '15 at 08:16
  • @rcgldr The compilers virtual machine reorders based on whether a change would impact execution in the context of a single thread. Thus, you are guaranteed that any actions within the same scope on the variable passed into CreateThread will occur prior to CreateThread (assuming the statements are written such that they occur prior to CreateThread in that scope). – Coder Jul 31 '15 at 08:22
  • @rcgldr Re: memory barrier API: https://msdn.microsoft.com/en-us/library/windows/desktop/ms684208%28v=vs.85%29.aspx – Coder Jul 31 '15 at 08:23
  • So the compiler doesn't reorder, but could there still be a multi-core reordering issue? – rcgldr Jul 31 '15 at 08:37
  • @rcgldr No, that's the purpose of the memory order guarantee. – Coder Jul 31 '15 at 08:40
  • @rcgldr I think my only problem here is the lack of an explicit guarantee with regard to CreateThread and _beginthread. From a conceptual point of view, it would likely cause havoc if developers could not assume that thread creation established a "happened before" relationship with the calling thread. – Coder Jul 31 '15 at 08:44
  • If the initial code of the created thread shared no variables with the creating thread, then a happened before relationship wouldn't matter during the execution of that initial code. – rcgldr Jul 31 '15 at 09:40
  • I'm about 99% sure that creating a thread explicitly establishes a "happened before" relationship on Windows, mainly because that would have been essential for backwards compatibility when Windows first introduced support for multiple cores. The fact that CreateThread doesn't mention it doesn't mean much; MS aren't good at documenting that sort of detail. Also, the new thread takes at least one lock before user-mode code starts executing, and I would imagine that thread creation claims a lock of some sort too - though I suppose that isn't necessarily true. It *would* be nice to see docs. – Harry Johnston Jul 31 '15 at 23:18

0 Answers0