Linux-kernel mailing list archive 2000-29,: Re: Cache coherency... and locking

# Re: Cache coherency... and locking

Davide Libenzi (davidel@maticad.it)
Fri, 21 Jul 2000 09:06:44 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Oliver Xymoron: "Re: disk-destroyer.c"
- Previous message: Andreas Gruenbacher: "BUG in fs/ext2/super.c"
- Maybe in reply to: Linda Walsh: "Cache coherency... and locking"
- Next in thread: Keith Owens: "Re: Cache coherency... and locking"

Friday, July 21, 2000 3:32 AM
Linda Walsh <law@sgi.com> wrote :

> Suppose I have a variable (a global int) that I'm going to read alot but
set
> infrequently. By my understanding, on x86SMP, it uses a
Exclusive/Shared/Invalid
> Bus protocol that when one processor changes a cache entry, all the other
> processors are sent invalidates for that cache line. So is it wrong to
> assume that if the only operations are the above, read frequent, and write
> rarely, I don't need locking?
>
> What about other platforms? If it is needed for say platform 'x' but the
lock
> isn't needed for platform x86, how is that handled? No reason to go
through
> a lock. If I am a running process, and I am looking at say, my audit
mask,
> do I need to lock it? Am I correct in assuming that the worst that could
> happen would be I catch it while someone else is writing it for 1 call
> and get only a partially written mask back? I know the writer has to at
> least lock some part of the process so the process won't "go away" in the
middle
> of the writer fiddling with it, but other than that, do I need any special
> locking on the mask itself?

Speaking about processor cache coherency in a multiple access mode look at
the intel developer site http://developer.intel.com/ for a document named
24319202.pdf - Chapter 9 "Memory Cache Control".
If You're speaking about a shared/exclusive resource access, in Your case,
even if You access very few times in writing, You need a SWMR
( Single Writer Multiple Reader ) locking method.
This kind of access method will have anyway a spinlock/semaphore to grant
eclusive access to its data structures, and this can generate a cache
ping-pong
( in MP case ) onto the cacheline(s) holding the spinlock/semaphore.

Davide

    --
    Feel free, feel Debian !

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

- Next message: Oliver Xymoron: "Re: disk-destroyer.c"
- Previous message: Andreas Gruenbacher: "BUG in fs/ext2/super.c"
- Maybe in reply to: Linda Walsh: "Cache coherency... and locking"
- Next in thread: Keith Owens: "Re: Cache coherency... and locking"