std::mutex does nothing without -pthread

[slowriot]

If the -pthread flag is not used when linking, std::mutex does nothing.

I imagine this seemed like a good idea at one stage, when the only way to get multithreaded behaviour was with -pthread. This also mirrors the (similarly surprising) behaviour of glibc when building without -pthreads: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929

However, it's currently possible to have a multithreaded program with web workers (-sWASM_WORKERS) without using pthreads, and having a working std::mutex is still very desirable in that situation.

A simple test program to confirm whether mutex is working as expected or not:

  std::mutex test_mutex;
  {
    std::cout << "locking 1" << std::endl;
    std::unique_lock lock1{test_mutex};
    {
      std::cout << "locking 2" << std::endl;
      if(std::unique_lock lock{test_mutex, std::try_to_lock}; lock.owns_lock()){
        std::cout << "lock 2 succeeded" << std::endl;
      } else {
        std::cout << "lock 2 failed" << std::endl;
      }
      std::cout << "anticipating deadlock after this point..." << std::endl;
      std::unique_lock lock2{test_mutex};
      // should not advance past this point due to deadlock
      std::cout << "unlocking 2" << std::endl;
    }
    std::cout << "unlocking 1" << std::endl;
  }

With -pthread enabled, this behaves as expected:

locking 1
locking 2
lock 2 failed
anticipating deadlock after this point...
[program freezes]

Without -pthread:

locking 1
locking 2
lock 2 succeeded
anticipating deadlock after this point...
unlocking 2
unlocking 1

It's worth noting that emscripten_lock_try_acquire and associated functions work fine both without -pthread, only the std::mutex behaviour is surprising.

[sbc100]

As of today the C++ standard library for std::mutex and std::thread all depend in pthreads. Using these primitives when building with -sWASM_WORKERS does not work.

There are a few ways it could be made to work:

1. Add WASM_WORKERS support for libc++
2. Add support for a subset of pthread APIs with WASM_WORKERS

I'm not sure either of these things are likely to a happen any time soon.

In the meantime I think we can/should probably abort() if pthread APIs are used in WASM_WORKERS builds, since doing so simply does not work, and is a sign that something is wrong.

[sbc100]

@juj

[slowriot]

Thanks for the background. I agree that at least abort() or some sort of warning on the console would help.

I've released a small drop-in replacement for std::mutex using Emscripten's WASM worker synchronisation API, which can be used as a workaround meanwhile: https://github.com/Armchair-Software/emscripten-sync

Ideally, std::mutex could be implemented in Emscripten directly in a similar way if building with WASM workers and without -pthread, which would make things a lot easier, but I imagine there are a lot of changes required in many places in libc++ for that to work.

[beforeface]

I have a question. When you complie wasm with -pthread, how could you use crwap call the wasm funciton that in EXPORTED_FUNCTIONS. I alwasy get wrong message, est.wasm.j…t=1739152379059:810 Aborted(Assertion failed: UTF8ToString expects a number (got undefined)). Please help me. Thanks