[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 #10 from Zebediah Figura <z.figura12 at gmail.com> ---
(In reply to Jacek Caban from comment #9)
> I took a look at the series and have some suggestions. It would be good to
> make NtAlertThreadByThreadId lock-free, but I'd suggest to try to do that in
> a spirit similar to fd cache. Looking at pid/tid allocation strattegy in
> server, we'd rarely need more than one cache array allocation for entire
> process.

The only problem with that is that if we run out of space in the fd cache, the
only effect is we have to go to the server each time. If we run out of space in
the TID/addr or TID/TEB mappings, the functions can't work. Maybe that's not
worth worrying about, though...

> 
> It should be possible to do tid->TEB mapping this way. Another possible way
> would be to simply map to a thread-specific int value. That value could be
> then used directly as a futex or HANDLE storage (and maybe some special
> value to be able to distinguish between non-waiting and non-existing tid, if
> needed).

You mean, map to the value directly rather than mapping to the TEB and looking
up the value from there? Sure, and if we make it lock-free that definitely
seems like a good idea.

> 
> For PE side of things, I wonder if you really need so complicated wait entry
> allocation. Could we just store wait entry on waiting thread's stack?

We need some way to append and arbitrarily remove it from a list of waiting
threads. It would have been better than the original approach (i.e. iterating
over TEBs), but it would still require locking (afaik only singly linked lists
can be lock-free, and you can't pop from the middle of one).

-- 
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.