Hi Bogdan, Bogdan Opanchuk <[email protected]> writes: > I personally do not mind the lock, as I won't notice an overhead so > small in my applications. I am just not completely sure about whether > such introduction is justified logically. You are saying that "it's > the only spot where the CL API is not thread-safe", but __call__ is > not CL API — set_args and enqueue_nd_range_kernel are. __call__ is a > convenience function that contains several calls to CL API, same as, > say, pyopencl.array.sum(). Does __call__ get special treatment because > it is somewhat closer to the "core" and used more often?
set_arg and enqueue_nd_range_kernel individually do not race, it's the combination of them that does. __call__ constitutes that combination, so it would need to be protected. That said, I'm inclined to follow what Brian said and simply say in the docs that if multiple threads enqueue a kernel, each should make its own copy. That's easy: prg.mykernel Doing that individually for each thread is no big deal, IMO, and it avoids this whole locking story. I'll add a remark to the docs once everyone has had a chance to reply. Andreas _______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
