# Advice on using unsafe\_wrap to view integers as atomic integers

**URL:** <https://discourse.julialang.org/t/advice-on-using-unsafe-wrap-to-view-integers-as-atomic-integers/67918>\
**Category:** General Usage\
**Tags:** question\
**Created:** [September 9, 2021, 8:35am UTC](https://discourse.julialang.org/t/advice-on-using-unsafe-wrap-to-view-integers-as-atomic-integers/67918 "2021-09-09T08:35:00Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![orenbenkiki](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/orenbenkiki/32/5578_2.png) [@orenbenkiki](https://discourse.julialang.org/u/orenbenkiki)\
**Post date:** [September 9, 2021, 11:55am UTC](https://discourse.julialang.org/t/advice-on-using-unsafe-wrap-to-view-integers-as-atomic-integers/67918/8 "2021-09-09T11:55:03Z")

</div>

@kristoffer.carlsson - thanks for the link to the presentation and for the explanation.

I suppose that whenever I have a `mutable struct Foo ... end`, then a `Vector{Foo}` will actually be implemented as an array of pointers to heap-allocated `Foo` objects rather than directly as an array of consecutive `Foo` objects. That would be consistent with Java, Python etc. and makes sense for a GC language. My only surprise is that such a mutable struct was chosen to implement `Atomic{T}` - definitely not what I expected given the zero-cost implementation in C/C++/Rust/etc.

Hopefully `@atomic` would allow for this zero-cost abstraction (though that wasn’t explicitly stated in the talk).

At least now all is clear - many thanks!

---

_[View the full topic](https://discourse.julialang.org/t/advice-on-using-unsafe-wrap-to-view-integers-as-atomic-integers/67918)._
