tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: __{read,write}_once
On Mon, Nov 11, 2019 at 01:15:16PM -0500, Mouse wrote:
> > Uninterruptible means exactly that, there is a clear before and after
> > state and no interrupts can happen in between.
>
> Is uninterruptible all you care about? Or does it also need to be
> atomic with respect to other CPUs? Eventually, of course, you'll want
> all those counter values on a single CPU - does that happen often
> enough to matter?
>
> Also, does it actually need to be uninterruptible, or does it just need
> to be interrupt-tolerant? I'm not as clear as I'd like on what the
> original desire here was, so I'm not sure but that we might be trying
> to solve a harder problem than necessary.
The update needs to be uninterruptable on the local CPU in the sense that
context switches and interrupts don't tear the R and W part of the RMW cycle
apart. x86 ALU instructions with memory operand as destination fit the
bill fine. It doesn't have to be atomic, no other CPU is supposed to
write to that cache line. It also generally doesn't matter whether they
see the old OR the new value, as long as it is either. We have full
control over alignment.
Joerg
- References:
- Re: __{read,write}_once
- From: Mindaugas Rasiukevicius
- Re: __{read,write}_once
- Re: __{read,write}_once
- From: Mindaugas Rasiukevicius
- Re: __{read,write}_once
- Re: __{read,write}_once
- Re: __{read,write}_once
- Re: __{read,write}_once
- Re: __{read,write}_once
- Re: __{read,write}_once
- Re: __{read,write}_once
Home |
Main Index |
Thread Index |
Old Index