# Atomic{T} types boxing and performance

**URL:** <https://discourse.julialang.org/t/atomic-t-types-boxing-and-performance/2257>\
**Category:** Internals & Design\
**Created:** [February 23, 2017, 9:24pm UTC](https://discourse.julialang.org/t/atomic-t-types-boxing-and-performance/2257 "2017-02-23T21:24:53Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![jpfairbanks](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jpfairbanks/32/4500_2.png) [@jpfairbanks](https://discourse.julialang.org/u/jpfairbanks)\
**Post date:** [February 23, 2017, 9:24pm UTC](https://discourse.julialang.org/t/atomic-t-types-boxing-and-performance/2257/1 "2017-02-23T21:24:53Z")

</div>

I was looking at the source for the Atomic operations and it looks like the Atomic{T} type is a mutable struct, which means that a Vector{Atomic{T}} is an array of references to the integers.

When using atomic operations with OpenMP and GCC atomic instructions, there is no need to have this layer of indirection. In this case there is no difference between an “array of ints” and an “array of ints on which I will use atomic instructions.”

Could we have a similar behavior in Julia? What would prevent this from being implemented?

---

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [February 24, 2017, 1:34pm UTC](https://discourse.julialang.org/t/atomic-t-types-boxing-and-performance/2257/2 "2017-02-24T13:34:31Z")

</div>

I have plan to change it though we can’t have an atomic field that’s inlined, rather atomic operations on normal fields.

---

<div class="post-metadata">

**Author:** ![rohitvarkey](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rohitvarkey/32/3158_2.png) [@rohitvarkey](https://discourse.julialang.org/u/rohitvarkey)\
**Post date:** [February 27, 2017, 4:04pm UTC](https://discourse.julialang.org/t/atomic-t-types-boxing-and-performance/2257/3 "2017-02-27T16:04:08Z")

</div>

I have been working on a package, [UnsafeAtomics.jl](https://github.com/rohitvarkey/UnsafeAtomics.jl/blob/master/src/UnsafeAtomics.jl) implementing atomic operations on `Array{T <: AtomicTypes}` which removes the layer of indirection @jpfairbanks mentions. I have got most of the atomic operations working on Arrays at this point (except FloatingTypes add, sub, min and max) and tests from Base passing for these operations.

I’ve been trying to get atomics to work on `Int` and `Float` types and not just `Arrays` but I’ve been getting [BoundsErrors](https://github.com/rohitvarkey/UnsafeAtomics.jl/issues/1) on passing the value of `pointer_from_objref` to the llvmcall. What could be the reason for this?

Is there a possibility for this functionality to be integrated into Base? If so, what changes should I make?

Thanks,  
Rohit

---

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [February 27, 2017, 4:12pm UTC](https://discourse.julialang.org/t/atomic-t-types-boxing-and-performance/2257/4 "2017-02-27T16:12:42Z")

</div>

> [@rohitvarkey](#):
>
> Is there a possibility for this functionality to be integrated into Base? If so, what changes should I make?

I don’t think that’s the correct approach. What I think what we need is an atomic operation that can operate on `Ref`s, which will also need to properly handle the GC write barrier for pointer refs. We also need a field ref typep so that it can be operated on fields too. Then we need the necessary optimizations in typeinf so that the operation is allocation-free.

[Unsafe atomic operations on T \<: AtomicTypes · Issue #1 · jpfairbanks/UnsafeAtomics.jl · GitHub](https://github.com/rohitvarkey/UnsafeAtomics.jl/issues/1) is impossible.