dlmalloc locks seems to be not enabled in pthread builds

[TerrorJack]

It seems that in the pthread builds, dlmalloc locks are not enabled, and this makes the libc allocator not thread-safe to use.

[abrown]

I thought that _REENTRANT got set and then USE_LOCKS will be defined?

https://github.com/WebAssembly/wasi-libc/blob/8daaba387ce70a6088afe3916e9e16ed1c2bc630/dlmalloc/src/dlmalloc.c#L19-L21

[TerrorJack]

Ah sorry, I missed the dlmalloc.c file! Yes, USE_LOCKS does get defined. Though it seems that currently spin locks is used in dlmalloc, which looks not ideal compared to futex based atomics.wait instruction?

[sbc100]

Yes we probably want to make sure USE_SPIN_LOCKS is not defined, so it will fallback to pthread locks.

[sbc100]

Here is where emscripten does that: https://github.com/emscripten-core/emscripten/blob/e64e3701c9c6d9fc2622fb34b92065971c326ed1/system/lib/dlmalloc.c#L29-L32

[TerrorJack]

I think there's an even bigger problem there; IIUIC pthread_mutex_lock in wasi-libc currently uses spinlock. We do have a futex-based lock at libc-top-half/musl/src/thread/__lock.c which gets used in some places, but not pthread lock itself. And also that futex lock doesn't take a timeout argument.

[sbc100]

As far as I can tell pthread_mutex_lock uses __wasilibc_futex_wait just like __wait.

Its just a rather indirect path:

pthread_mutex_lock -> __pthread_mutex_timedlock __pthread_mutex_timedlock -> __timedwait __timedwait -> __timedwait_cp __timedwait_cp -> __futex4_cp __futex4_cp -> __wasilibc_futex_wait

Is your analysis different to mine?

[TerrorJack]

Ah, that makes sense to me now! Thanks a lot for the clarification.