fix: Make CUDA shared memory stream cache thread-safe in Python client

[jpbhdrey]

I opened this draft to discuss possible solutions to issue #914.

The simplest possible solution is just adding a lock inside the _get_or_create_global_cuda_stream. With this lock, just one thread enters the global cuda stream creation clause at a time. And, of course, operations in a cuda stream are guaranteed to be serialized, so no problem in two python threads "owning" it.

I also considered changing the return to an actual CudaStream instance, but then it would change the intention of a unique cuda stream per device, as it is written right now, and I would need to change the callers as well.

I opened this as a draft because there are comments in the __del__ methods in the wrappers of some cuda resources at cuda_shared_memory._utils and CudaSharedMemoryRegion could also suffer from the same problem.

If you run the same reproducing script in the respective issue, it will run without errors. I don't know if this could be implemented as a test because it need GPUs.

[greptile-apps]

Greptile Summary

This PR makes creation and lookup of the process-global CUDA stream cache thread-safe.

• Adds a module-level lock for _dlpack_stream.
• Serializes cache lookup and CudaStream creation per process.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete blocking or non-blocking defects identified in the changed code.

The lock covers the complete cache lookup-and-create critical section, releases correctly on construction errors, and introduces no supported re-entrancy, lifetime, or lock-order failure.

Important Files Changed

Filename	Overview
src/python/library/tritonclient/utils/cuda_shared_memory/init.py	Protects the CUDA stream cache’s lookup-and-create sequence with a lock, preventing concurrent creation of duplicate streams for one device.

_{Reviews (1): Last reviewed commit: "fix: Make CUDA shared memory stream cach..." | Re-trigger Greptile}