5

(This may be a general question for atomic increment/decrement but I have encountered the situation in the realm of shared_ptrs)

Does a shared_ptr encounter two cache line misses/accesses- when the atomic reference counter is incremented and decremented?

I did find this:

atomic operation cost

but it doesn't seem to be overly conclusive....

UPDATE:

If I run a loop millions of times, incrementing an atomic variable I get a L1 cache miss rate of 0.2. If I do the same with a non-atomic int I get 0 L1 cache miss rate.....

The test would imply the L1 cache line is being evicted.

Community
  • 1
  • 1
user997112
  • 29,025
  • 43
  • 182
  • 361
  • Sorry, it's not an nswer. I'm not an expert in atomic operations, do I won't argue on how costly they are. However, I could debate the fact of calling this operation at all. I wonder in which scenario does it matter for you? If pointer was created with make_shared, obviously the cache line with reference and the data will be read once, so you could say it's one less cache miss. Next, thanks to move operator, reference count won't be changed when moving shared_ptr (say, resize of std::vector ). – Artem Tokmakov Jun 05 '14 at 20:42
  • Thats not entirely true. If your object is larger than cache_line_size and you read a data member declared at the beginning, you'll end up with two cache line reads. – user997112 Jun 06 '14 at 08:14
  • You're right ) Though I'd think it's a rare case. – Artem Tokmakov Jun 24 '14 at 04:33

1 Answers1

0

shared_ptr has to store the reference counting variable somewhere. It is likely allocated from the heap and the shared_ptr contains a pointer to this variable.

It is entirely possible that having to access this variable will cause cache operations unless care has been taken to put them in the same chunks, which is highly unlikely.

If you are worried about the performance implications of this, make a class with an integer to count references, a custom pointer class that uses it, and derive every class that you want to manage like this from your reference counting class.

deek0146
  • 962
  • 6
  • 20