# New Issue: Provide atomic operation wrappers to be used in GPU kernels

**URL:** <https://chapel.discourse.group/t/new-issue-provide-atomic-operation-wrappers-to-be-used-in-gpu-kernels/21355>\
**Category:** Issues\
**Created:** [April 25, 2023, 6:33pm UTC](https://chapel.discourse.group/t/new-issue-provide-atomic-operation-wrappers-to-be-used-in-gpu-kernels/21355 "2023-04-25T18:33:11Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![e-kayrakli1](https://yyz2.discourse-cdn.com/free1/user_avatar/chapel.discourse.group/e-kayrakli1/32/315_2.png) [@e-kayrakli1](https://chapel.discourse.group/u/e-kayrakli1)\
**Post date:** [April 25, 2023, 6:33pm UTC](https://chapel.discourse.group/t/new-issue-provide-atomic-operation-wrappers-to-be-used-in-gpu-kernels/21355/1 "2023-04-25T18:33:11Z")

</div>

22155, "e-kayrakli", "Provide atomic operation wrappers to be used in GPU kernels", "2023-04-25T18:32:59Z"

> <https://github.com/chapel-lang/chapel/issues/22155>
>
> Spin-off from https://chapel.discourse.group/t/mixing-atomic-add-with-non-atomic…-read-and-towards-gpu-atomics/21350
> 
> This issue asks for a short-term solution for atomics support in GPU kernels. Particularly, wrapping functions like \`atomicAdd\` via a standalone function in the GPU module would go a long way for supporting different idioms. Note that, what those functions will provide is atomic operations on non-atomic types. We have a general desire to support that and vice versa in the language. But that's a post 2.0 effort and we should not wait for that. Maybe what we learn from GPU programming can help steer the design for that feature down the road. @ronawho will capture his thoughts on the general matter soon.
> 
> Another related question in my mind is: what does/should happen with \`atomic\` types in GPU kernels as they exist today?

Spin-off from [Mixing atomic add with non-atomic read? (and towards GPU atomics)](https://chapel.discourse.group/t/mixing-atomic-add-with-non-atomic-read-and-towards-gpu-atomics/21350)

This issue asks for a short-term solution for atomics support in GPU kernels. Particularly, wrapping functions like `atomicAdd` via a standalone function in the GPU module would go a long way for supporting different idioms. Note that, what those functions will provide is atomic operations on non-atomic types. We have a general desire to support that and vice versa in the language. But that's a post 2.0 effort and we should not wait for that. Maybe what we learn from GPU programming can help steer the design for that feature down the road. @ronawho will capture his thoughts on the general matter soon.

Another related question in my mind is: what does/should happen with `atomic` types in GPU kernels as they exist today?