https://bugs.winehq.org/show_bug.cgi?id=50292
--- Comment #13 from Jacek Caban jacek@codeweavers.com --- (In reply to Zebediah Figura from comment #12)
(In reply to Jacek Caban from comment #11)
We can ensure that the cache slot is allocated somewhere in NtCreateThreadEx, where we can properly propagate error.
I guess putting a hard limit on the number of threads works too...
I'm not sure how that would help, I guess that we're thinking about different implementation details. There is a global limit of threads implied by the fact that thread ids are 30 bits (a DWORD value with two least significant bit ignored). We could have tid_cache similar to fd_cache:
- in NtCreateThreadEx: ensure that tid_cache[tid >> tid_cache_shift] is allocated and mark tid_cache[tid >> tid_cache_shift][tid & tid_cache_mask] as valid
- in NtWaitForAlertByThreadId and NtAlertThreadByThreadId: use only tid_cache for thread-specific data
- when terminating thread: mark appropriate tid_cache as invalid
FWIW, we wouldn't need to pop from a middle if we had a separated lists for each address. The problem would be lock-free mapping from input address to such a single listed list. This could be done, but 64-bit key size makes it much less appealing (than, say, 30-bit key for fd cache).
Applying a hash map might help in general. I'm not sure how even separate lists for each address helps us, though. The waits have an arbitrary timeout, so it'd still be possible to pop from the middle.
Oh right, I forgot about timeouts.