[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