Re: Cache coherency... and locking

From: Davide Libenzi (davidel@maticad.it)
Date: Fri Jul 21 2000 - 02:06:44 EST


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/



This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:15 EST