Alguns dos códigos atuais tem sido simplificados para propositos espesificos.
Considere um cache virtualmente catalogados que é escrito de volta write-back. Neste momento que a cópia da página acontece para o supisto espaço kernel, é possivel para usar space a visão da página original para estar no caches (no endereço do usuário, por exemplo, onde o erro esta ocorrendo). A cópia da página pode trazer este dado (para a página velha) dentro do caches. Será também colocado o dado (no novo suporte kernel mapeado da página) sendo copiado para dentro da cache, e para write-back escrever de volta chachas este dado vai ser sujo ou modificado no cache.
Em tal caso a memoria principal não será a cópia mais recente do dado. Os caches são estúpidos, então para a nova página que estamos dando ao usuário, sem forçar o dado cached no suposto kernel para a memória principal o processo será o conteúdo velho da página. (Por exemplo qualquer lixo que estarem lá antes da cópia ter sido feita pelo processamento
COW acima).
4.7.3.1 – Exemplo concreto de flush-page
Considere um processo que divide uma página, lê somente READONLY com maior uma tarefa (ou varias) no endereço virtual Ox2000, no usar space. E para propósito espesíficos deixe nos dizer que este endereço virtual mapeia para a página física 0x14000.
Se a tarefa 2 tenha escrever para a página lê apenas no endereço 0x2000 nós alteremos um esso e (eventual fragmento do código) mente resultado no code fragment mostrando acima no do-WP-PAGE ( ).
O Kernel vai obter uma nova página para tarefa 2, deixe-nos dizer que esta e uma página física 0x2600, e deixe-nos tambem dizer que os mapeamentos do suposto Kernel para páginas físicas 0x14000 e 0x26000 podem residir em dias únicos linhas cache ao mesmo tempo buscando no esquema da linha catalogada deste cache.
O conteúdo da página e copiado do mapeamento Kernel para página física 0x14000 para uns para página física 0x26000.
Neste momento, numa arquitetura cache virtualmente catalogada write – back nos temos uma inconsistência potencial. O novo dado copiado dentro da página física 0x26000 não e necessário na memória principal neste momento, de fato isto poderá estar toda no cache apenas no suposto kernel do endereço físico.
Também, o (não modificando, por exemplo, limpo) dado para a (velha) página original esta no cache do suposto kernel para página física 0x14000, isto pode produzir uma inconsistência mais tarde, então para proteger isto e melhor eliminar as cópias cached deste dado também.
Deixe-nos dizer não escrevemos os dados de volta para a página no 0x256000 e nos apenas deixamos isto lá. Nos retornariamos para a tarefa 2 (Quem teve esta nova página agora mapeada no endereço virtual 0x2000) ele completaria sua escrita, então ele leria algumas outras porções de dados nesta nova página (por exemplo, esperando o conteúdo que existe lá antes).
Neste momento seo dado e deixado no cache no suposto kernel para nova página física, o usuário obterá o que que estava na memória principal antes da cópia para sua leitura. Isto pode levar a resultados dasastrosos.
4.7.4 – Conteúdo de uma arquitetura virtual
Numa arquitetura cache virtualmente catalogada, fica o que foi necessário para fazer a memória principal consistente com a cópia cached da página passada do espaço kernel.