Option<AtomicPtr<Node>> vs AtomicPtr<Option<Node>>

The struct Node is a linked list node. There is a vector which will contain a bunch of linked lists.
What should I make the elements of the vector, if I want to atomically (using CAS) add elements to the head of a list. Should it be Option<AtomicPtr> or AtomicPtr<Option>? Or anything else is suitable for the purpose??

PS: I am just experimenting with the std::sync::atomic and memory orderings. So I don't know what I am doing is right or wrong. Any feedback is welcome

1 Like

On thinking a bit more about this, does AtomicPtr< None > even make sense?

I'd just use AtomicPtr<Node>. An AtomicPtr can be null, so you kinda already have a None variant.

Also, what is the reasoning for using AtomicPtr instead of raw pointers?

( obligatory link to Learn Rust With Entirely Too Many Linked Lists)


Thanks. I didn't know that AtomicPtr can be null. This makes my work easier.
As for the reason why I am using AtomicPtr, I wanted to learn about Atomics, Memory Ordering, CAS and other cool stuff in lockless programming. So I decided to make a hash table which can be called by multiple threads and be lock-free. I don't know if I will achieve the goal but it has been fun so far.

So I didn't find any API in rust std::sync::atomic which performs CAS on a normal raw pointer. Then I found compare and swap methods on the atomic variants and decided to use them for the purpose.

Is there any way that I can check for null? The docs don't mention anything about that.

Load the atomic pointer, which gives you a *mut T, then call is_null on that.


I would highly recommend checking out Jon Gjengset's streams on porting Java's ConcurrentHashMap to Rust. This sort of thing can be tricky to get right and I learned a lot about concurrency and unsafe by watching him go through the process of understanding and porting an existing concurrent HashMap implementation.


Thanks. I will

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.