Giter Club home page Giter Club logo

Comments (5)

karlseguin avatar karlseguin commented on July 23, 2024 1

merged 3385784

from ccache.

karlseguin avatar karlseguin commented on July 23, 2024

I think the problem is that size is only ever accessed in the worker thread. So simply reading it from another thread is an undefined behaviour.

Could make it thread-safe by making all access go through atomic.XXX. But then the worker pays a performance penalty.

Could also achieve this via a channel. Add a GetSize() int function which sends a message via channel to the worker. But that might be relatively slow (relatively to what you expect getting the size would take) since the worker could be busy.

What do you think?

from ccache.

lozaeric avatar lozaeric commented on July 23, 2024

Yes, of course. I guess a "dirty read" is not that bad. In my use case, an approximate information would be useful.

Although, make it by using atomic pkg could be the best way. I think performance penalty would be minimal.

Iā€™m working on improving my English. Please, let me know if you don't understand.

from ccache.

karlseguin avatar karlseguin commented on July 23, 2024

I understood everything perfectly :)

Without proper locking, the read wouldn't just be "dirty", the behavior would be undefined. Googling this, the general answer is: on most architectures, read on a word-sized integers is atomic, but you shouldn't rely on it. The worst case, but probably only theoretically at this point, is that you'd crash the entire operating system.

But even if we ignore this, there's no guarantees about of how "dirty" it can be. It's not crazy to think that the worker always runs on the same core/socket and since we can't flag the field as "volatile" other cores/sockets read extremely stale data from their caches.

What do you think of: 3385784 ??

Instead of exposing size, it exposes an ItemCount. Of course, ItemCount will only be equal to size when all the items in the cache are given a size of 1. But even when that isn't the case, I think knowing the number of items in the cache is still meaningful for debugging / monitoring.

The benefit of this approach is that there's 0 performance hit for anyone who doens't care about ItemCount. And, ItemCount is still pretty fast to calculate.

from ccache.

lozaeric avatar lozaeric commented on July 23, 2024

You're right. I thought stale read was the only issue but it's more complicated. Thak you for explaining

Yes, of course, ItemsCount is useful for monitoring / troubleshooting.

from ccache.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    šŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. šŸ“ŠšŸ“ˆšŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ā¤ļø Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.