[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