Hi all, thanks for your attention.
Carlos O'Donell wrote:
> On UP you have a problem:
> * Thread A enters LWS CAS (no lock on UP)
> * Thread A writes to CAS address causing COW
> * Thread A sleeps.
> * Thread A completes COW, but finishes time slice before the write is restarted.
> * Thread B enters LWS CAS (no lock on UP)
> * Thread B writes to CAS address, and finishes time slice.
> * Thread A writes to CAS address and clobbers B's value.
I thought like that:
(condition like a young process, or a process after fork
which occurs COW)
* Thread A enters LWS CAS (no lock on UP)
* Thread A writes to CAS address causing COW
* Thread A sleeps for new memory.
Kernel process scheduling:
Thread A sleeps
-> swapper wakes up and got new memory, then sleep
-> Thread B wakes up
* Thread B enters LWS CAS (no lock on UP)
* Thread B writes to CAS address, causing COW, this time we have memory.
Writes completes, and finishes time slice.
Kernel process scheduling like that:
Thread B sleeps -> Thread A wakes up
* Thread A writes to CAS address and clobbers B's value.
Today, I have a next question. Is there any cache alias problem here?
Should we invalidate the cache line before "load" and flush the cache
line after "store"?
I am testing on paer.debian.org. It says D-cache is wribe back,
and that's my concern.
--------------------------
Welcome to paer.debian.org, the Debian hppa porterbox
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Last login: Wed Mar 31 02:31:27 2010 from 150.82.175.29
gniibe@paer:~$ cat /proc/cpuinfo
processor : 0
cpu family : PA-RISC 2.0
cpu : PA8700 (PCX-W2)
cpu MHz : 750.000000
capabilities : os64
model : 9000/800/A500-7X
model name : Crescendo 750 W2
hversion : 0x00005e30
sversion : 0x00000491
I-cache : 768 KB
D-cache : 1536 KB (WB, direct mapped)
ITLB entries : 240
DTLB entries : 240 - shared with ITLB
bogomips : 1495.04
software id : 822930640
--------------------------
--
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
