Please hurry up

[boris-kolpackov]

Hi,

First, thanks for working on this!

I would also like to urge you not to wait until it's perfect and potentially just releasing the SRW-based implementation without using internal/undocumented APIs even if it's sub-optimal (or even incomplete). The reason for this is that, in our experience, the only alternative (POSIX threads via winpthreads) is not just sub-optimal/heavy-weight/etc., but broken. There seem to be some rarely-occurring race conditions or similar issues. See here for details: https://github.com/build2-packaging/libmingw-stdthread

So we desperately need a replacement.

Again thanks for your work!

[lhmouse]

What is 'the SRW-based implementation'? We don't make use of SRWLOCKs at all, due to some defects:

1. SRWLOCK does not supported timed wait operations.
2. CONDITION_VARIABLE does not support absolute timeouts, and the 32-bit timeout value in milliseconds can easily be overflowed.
3. It would take more space (3 pointers) to implement semaphores, than use keyed event directly (1 pointer).

[boris-kolpackov]

I believe the above-linked implementation uses SRWLOCK for the plain mutex and shared_mutex and CONDITION_VARIABLE for condition_variable, which, in my experience, is what the majority of code uses (I've never needed timed_* or recursive_* versions of mutexes in my life).

All your listed defects are probably true (I am not an expert like you), but my point is that a deployed implementation that has issues that you have listed is still infinitely better than what we currently have, which, in my experience, is just not usable at all.

So I was hoping to encourage you to deploy something sooner rather than wait for something perfect. But seeing that you are doing the work and I am just cheer-leading, it is, of course, your decision to make.

Again, thanks for working on this.

[lhmouse]

I have prebuilt toolchains at https://gcc-mcf.lhmouse.com/, which are quite experimental. I am not sure how many people will be interest in it, however; my job isn't about Windows.

Thanks for your interest.

[boris-kolpackov]

I've tried to bootstrap build2 using mingw-w64-gcc-mcf_20220510_12.1.1_x64-msvcrt_16bb4fa373a8231476ff80ede7f3bff6888dad98 and, yes, there seem to be some issue with TLS (we use thread_local but on variables that don't require dynamic initialization/destruction).

my job isn't about Windows

Mine neither but somehow I always end up fixing Windows issues ;-).

[lhmouse]

What is the issue?

[boris-kolpackov]

I haven't investigated in detail but in summary it appears a TLS variable ends up with a wrong value which triggers an assert here: https://github.com/build2/build2/blob/master/libbuild2/algorithm.ixx#L227

The variable in question is here: https://github.com/build2/build2/blob/master/libbuild2/algorithm.cxx#L205

I can provide instructions on how to reproduce this.

[lhmouse]

Some recommendations:

1. Try __thread instead of thread_local and see whether it works.
2. Use __gthread_setspecific() and __gthread_getspecific() (they work the same way as the pthread ones) and see whether they work.
3. Use native TlsGetValue() and TlsSetValue() and see whether they work.

Also, if you call unlock() in the destructor of a static object, all thread-local ones will have been destroyed, which is also likely to cause such errors.

This thread_local thing is emulated in libgcc with a lookup table, which is associated with a thread-specific value. I only provide the __gthread_setspecific() thing; the other parts are provided by GCC.

[boris-kolpackov]

Thanks for the pointers. I've studied the assembler output of __thread and thread_local usage and they result in identical output at least for my use-cases. I would like to find time to debug this as you have suggested but unfortunately that's unlikely to happen.

[lhmouse]

We have some testcases in test. I also tried other pthread testcases (e.g. from GNU lib) which required some text replacement. All of them passed. If you would like to report a bug, please do attach one that fails for you.