i checked the code on sources again and found the issue. the lookpage() in 9front is different. we lock the page from the image cache hash chain and check if the page is still cached and for the right disk address under the lock.
but if it changed or got uncached by duppage(), we unlock and *retry* instead of giving up the search. so duppage() appears atomic on 9front, but on labs, a process already commited to use that page in lookpage() will get a uncached page after the lock() succeeds and miss the (potential) new page put in by duppage(). but what you describe is possible with pio() in general. a process decides to demand load a page in pio() when lookpage() doesnt return a cached page. if multiple processes compete on loading the same page while its not in the cache, they will indeed do so. in the case that they share the segment, it will get deduplicated after the load and the page of the first process finishing the load wins, the other pages will be put back on the freelist (uncached). if they use distinct segments, they (the processes) will all cache ther pages in the image and the image will end up with multiple pages caching the same disk address of the file. it would be nice if the SP9SSS could speak out in detail on how they do page caching differently than classic plan9. -- cinap
