[flang][runtime] Remove dependency on C++ <mutex> on Windows

[mmuetzel]

Summary

The implementation of the Lock class on Windows currently uses C++ mutexes. That introduces a dependency on the C++ runtime on that platform.

Use a Windows CriticalSection instead of a std::mutex to avoid that dependency.

This works for me with MinGW (tested in a CLANG64 environment of MSYS2).

See also D126291.

This is the first time I'm uploading a patch to Phabricator. So, please let me know if this isn't the right way to propose changes.

[mmuetzel]

Attempt to fix compilation error with MSVC.

[mstorsjo]

Looks reasonable to me, but I'll leave it up to someone else more involved in flang to approve.

[klausler]

This patch oversimplifies the code, making it work only for WIN32 and with pthreads, but no longer with C++ mutexes.

[mmuetzel]

In D127316#3567905, @klausler wrote:

This patch oversimplifies the code, making it work only for WIN32 and with pthreads, but no longer with C++ mutexes.

The previous logic undefined USE_PTHREADS only on Windows and defined it to 1 everywhere else.
This change proposes an alternative implementation on Windows. It would be possible to leave in the code that uses std::mutex. But that part of the code would be essentially dead, and there would be no condition under which it would be compiled.

I can do that change. Just would like to confirm that this is really what you'd like to have.

[klausler]

Yes, please.

[mmuetzel]

Leave in (unreachable) code that uses std::mutex.
Ok like this?

[rovka]

Hi @mmuetzel,

Thanks for submitting this! I think the NOMINMAX trick should fix the issues I was seeing on Windows on Arm, but I still need to test to be sure (it's slow...). Do you have commit access or should I commit on your behalf?
One small Phabricator nitpick: it's nice to upload patches with context (you don't have to do that for this patch, I was just mentioning it for the future).

[mmuetzel]

In D127316#3572625, @rovka wrote:

Hi @mmuetzel,

Thanks for submitting this! I think the NOMINMAX trick should fix the issues I was seeing on Windows on Arm, but I still need to test to be sure (it's slow...). Do you have commit access or should I commit on your behalf?

I don't think I have commit access (unless there is some phabricator magic going on behind the curtains that I'm not aware of). I'd be happy if you could push this to the repo (if/when your tests have been successful).

One small Phabricator nitpick: it's nice to upload patches with context (you don't have to do that for this patch, I was just mentioning it for the future).

Thanks for the hint. I'll try to remember that in the future.

flang/runtime/lock.h

 
 #if USE_PTHREADS
 #include <pthread.h>
+#elif defined(_WIN32)
+// Do not define macros for "min" and "max"
+#define NOMINMAX
+#include <windows.h>
 #else
 #include <mutex>
 #endif

   }
   bool Try() { return pthread_mutex_trylock(&mutex_) == 0; }
   void Drop() { pthread_mutex_unlock(&mutex_); }
+#elif defined(_WIN32)
+  Lock() { InitializeCriticalSection(&cs_); }
+  ~Lock() { DeleteCriticalSection(&cs_); }
+  void Take() { EnterCriticalSection(&cs_); }
+  bool Try() { return TryEnterCriticalSection(&cs_); }
+  void Drop() { LeaveCriticalSection(&cs_); }
 #else
   void Take() { mutex_.lock(); }
   bool Try() { return mutex_.try_lock(); }

 private:
 #if USE_PTHREADS
   pthread_mutex_t mutex_{};
+#elif defined(_WIN32)
+  CRITICAL_SECTION cs_;
 #else
   std::mutex mutex_;
 #endif