Jose, On Saturday, January 12, 2013 17:22:03 Jose Fonseca wrote: > That work has been merged (w/ LLVM 3.1 and MC-JIT support), however it's > quite likely that's there are still race conditions, as nobody has been > pursuing llvmpipe thread-safety so far.
Given the findings that lead to commit 926a4a922f9a5ec397cb3d316dd915b00b39c54d llvm_start_multithreaded must be called pripor to concurrent llvm use. There are some globals, IIRC at least something in a pass registry which is guareded by a mutex if the above function is called. I have no clue if there is a better place for a call of this initialization function. So, if you have a better idea to move them so that llvmpipe and r600g have that set? Well, also now that I remember, I have placed that into a c++ constructor since the call to the above function itself must be serialized and is not allowed to run concurrently to any other llvm call. So, since we can concurrently create contexts from multiple threads we have nothing that we can do except letting that be serialized by the dynamic loader like we are in a static variable constructor. Of course this works only reliable if we are the only user of llvm in the calling application. If there are others sharing the same llvm dynamic library we are just out of luck then. If we really nail llvm privately into the dynamic llvmpipe/r600g module we are fine with the first part of the above argument since we are the only one accessing our private llvm instance then and being serialized by our own dynamic library initialization will be sufficient. Greetings Mathias _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
