[PATCH 1/2] advapi32: HKCR merge: foundation

Alexandre Julliard julliard at winehq.org
Fri Oct 25 10:21:41 CDT 2013

George Stephanos <gaf.stephanos at gmail.com> writes:

> On Fri, Oct 25, 2013 at 10:31 AM, Alexandre Julliard
> <julliard at winehq.org> wrote:
>     George Stephanos <gaf.stephanos at gmail.com> writes:
>     > You need some sort of free list instead of a linear search.
>     >
>     > Alright.
>     >
>     > Also you can probably avoid one level of pointers and store
>     > objects directly.
>     >
>     >
>     > I thought about this. If I store objects directly, accessing any
>     would
>     > require a lock on the whole table so I guarantee it's not moved
>     or
>     > reallocated elsewhere. This would obviously be pretty slow.
>     You already have a lock on the whole table anyway.
> I do. But it's only used when creating new handles or on table
> reallocations.
> Earlier I could reallocate the table without worrying about the
> handles.
> In your case that same lock would have to be grabbed when 
> *accessing* any of the handles so I make sure the table is 
> not being reallocated.
> That results in: no two handles can be accessed concurrently as
> opposed 
> to my current code where they can.
> I might be missing something though :|

You still have to grab the lock on every access; I very much doubt that
releasing it a little earlier is going to make a difference.

Of course you can make things faster by making them non thread-safe, but
that's not a good idea.

>     > Returning a pointer to the object outside of the critical
>     section
>     > is not
>     > a good idea.
>     >
>     > The critical section just protects the table and not the
>     > handles/structs themselves.
>     Yes, that's the problem. The structs have to be protected too.
> Maybe a lock inside each struct?

You would need to demonstrate an real app that shows heavy contention on
that lock to make it worth the trouble.

Alexandre Julliard
julliard at winehq.org

More information about the wine-devel mailing list