[Bug 50292] Process-local synchronization objects use private interfaces into the Unix library

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50292

--- Comment #13 from Jacek Caban <jacek at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.