Advertisement

Race conditions between thread groups

Started by January 12, 2019 10:52 AM
2 comments, last by Makusik Fedakusik 6 years, 1 month ago

Hi! 

In a dispatch with multiple groups, suppose the following: 

 

Thread Group A: 

- Thread1 in the group  read, modify and then write UAV[x,y]  --- NOTE no other thread in groupA handles to UAV[x,y]

 

Thread Group B: 

- Thread28 in the group ends up reading, modifying and then writing UAV[x,y] as well. -- NOTE no other thread in groupB handles to UAV[x,y]

 

 

What happens? Do I get race conditions between groups? If so, what could be an efficient strategy to avoid this? 

 

I assume they do, if so, do atomic operations (i.e. Interlocked etc.) work across multiple groups on UAVs? Also, what performance penalty may I incur? 

You will have to use atomic operation for this. The performance penalty will depend on the access pattern - how often the atomic is accessed - and it usually means some small added latency to the shader, which might be acceptable for you, but you have to test it.

If that value you writing is a single counter, you can also use append/consume buffers which come with a hidden counter that might be implemented in hardware a bit differently than atomic operation to UAV and thus be faster.

Advertisement

What do you get? Data corruption? use shared_mutex and unique_lock for modify. And shared_lock for reading. Or use some flags and conditional_variable

This topic is closed to new replies.

Advertisement