[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