[Mesa-dev] [PATCH] glsl: Make access to type flyweight global state thread safe
Kenneth Graunke
kenneth at whitecape.org
Sat Oct 27 11:30:37 PDT 2012
On 10/25/2012 11:17 AM, Eric Anholt wrote:
> Ian Romanick <idr at freedesktop.org> writes:
>
>> From: Ian Romanick <ian.d.romanick at intel.com>
>>
>> This should fix some problems related to compiling shaders in different
>> contextes from multiple threads.
>
> This is pretty nasty. I think de-rallocing this file might end up nicer
> (we'd need a destructor that frees type->name and type->fields.whatever,
> and a hash walk that calls it in _mesa_glsl_release_types and frees the
> key string), then mutexes would only be needed for the structure/array
> hash table inserts with no recursion issues.
>
> Does that sound reasonable?
Yeah...the random booleans everywhere is pretty nasty. This is usually
the sort of thing you do as a last resort...let's try something else first.
Eric's suggestion of de-rallocing makes sense to me. Making the fields
allocated normally (new/delete/delete[] via ctors/dtors) is
straightforward and removes the contention on mem_ctx.
The top-level allocation of glsl_type objects appears to be done without
ralloc already, which surprised me.
At that point, you should really only have to lock the hash table
insertions in get_array_instance() and get_record_instance(), which
seems quite reasonable.
More information about the mesa-dev
mailing list