<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 16, 2013 at 12:04 PM, Nico Rieck <span dir="ltr"><<a href="mailto:nico.rieck@gmail.com" target="_blank">nico.rieck@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On <a href="tel:13.10.2013" value="+13102013" target="_blank">13.10.2013</a> 04:07, David Majnemer wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Can we have a better name than 'futex' for these?  Futex is a Linux kernel<br>
synchronization primitive and it's a bit confusing that you used the name<br>
here in this context.<br>
</blockquote>
<br></div>
Sure. I initially chose it because it's short and kind-of similar in that it also locks on an arbitrary pointer address.<br>
<br>
On 15.10.2013 02:55, G M wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
* __mutex_base - I need the __yield function to be something like this for<br>
me to compile, otherwise I get compiler errors:<br>
</blockquote>
<br>
It's just a missing include. Technically sched_yield is not part of pthreads, even though Mingw implements it there. Since the implementation is the same there's no need to further special case it.<br></blockquote>
<div><br></div><div>sched_yield() is part of the POSIX standard, same as pthreads. They were both part of the 'Threads option' in SUSv3 and both migrated to 'Base' in SUSv4.</div><div><br></div><div>Also, please do not use __yield on Windows, it is apparently semantically equivalent to an x86 PAUSE instruction.  A suitable replacement for sched_yield() on Windows would be SwitchToThread().</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
* General statement: Can we follow the pthread model more closely here for<br>
libcxx's Win32 path. Is there any good reason not to? i.e. with futex<br>
becoming pthread_mutex etc. etc.? I think pthreads is a pretty tight and<br>
well known interface and I think we should aim to have a default<br>
implementation in libcxx that is easily swappable for anyone else's<br>
implementation or even if it's not hot swappable so to speak. have the<br>
win32 model more closely follow it.<br>
</blockquote>
<br>
It's not intended as a pthreads port, and the features are far from complete for that. For one, there's no single mutex type for recursive and non-recursive mutexes. If someone is so inclined he can force usage of pthreads and use an external lib. Mimicking pthreads but only implementing a small part of it will only lead to problems.<br>

<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
* The _LIBCPP_PTHREADS macro name is a little confusing to me. I think it<br>
means, "use the existing path that say libcxx uses for pthreads today,<br>
otherwise using the new / built in one".<br>
</blockquote>
<br>
It just means "use pthreads". It's never used in negative checks, and the second path is always conditioned on _WIN32 being defined.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
* The inline assembler might be able to be factored out, or out more:<br>
The win32 platform and clang appear to support the intrinsic bit test<br>
functions and see their are psdk intrinsics that provide the same thing.<br>
</blockquote>
<br>
Last I checked Clang doesn't support the MSVC bts intrinsic.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
* Some thought / additional code might be required in cmakelists.txt to<br>
make all this work properly i.e. finding the right headers / libraries,<br>
making sure the additional required libraries get brought in for pthreads.<br>
I haven't got that far yet. On my machine I get missing symbols with this<br>
patch re. NtXXX functions. They aren't hard to resolve, but it would appear<br>
(if I'm correct) that by default these libraries aren't wired up for msvc<br>
etc yet.<br>
</blockquote>
<br>
Patch 2 adds ntdll.dll to the linker so not sure what's going wrong there.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
* Phabricator. This patch might benefit from being discussed there. I<br>
haven't used it before nor have an account yet but I'll get one if that's a<br>
shared opinion. What do people think?<br>
</blockquote>
<br>
Too bad Phabricator doesn't support patch chains so you have to mash everything together. Multiple Phab entries that depend on each other are also a PITA.<br>
<br>
Thanks for looking at this.<span class=""><font color="#888888"><br>
-Nico<br>
<br>
</font></span></blockquote></div><br></div></div>