 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Eugene B. Berdnikov 2:5020/400 12 Mar 2001 20:04:12 To : "Vladimir Butenko" Subject : Re: Microsoft предлагает запретить Linux!!! -------------------------------------------------------------------------------- Vladimir Butenko <butenko@stalker.com> wrote: VB> Так я потому и написал - "пояснять?". Фишка в том, что на многопроцессорной VB> машине никто Вам не гарантирует, что при выполнении: VB> VB> a : int := 0; VB> VB> thread1: VB> VB> а := 1; VB> ..... VB> VB> thread2: VB> b := a; VB> VB> в b попадет именно 1 ДАЖЕ ЕСЛИ ВЫ ПОЛHОСТЬЮ УВЕРЕHЫ, что в VB> оператор во втором треде выполнится позже. Причина - в кэшах процессоров, VB> который вовсе не обязаны сбрасывать все в память сразу, а также инвалидить VB> кэш других процессоров при каждой записи в память. О как. А я, наивный, всю жизнь полагал, что на многопроцессорной системе всегда есть writeback, т.е. передача тага процессора, модифицировавшего память, в контроллер, отвечающий за когерентность кэша. Чтобы никто больше не посмел это слово модифицировать, не попросив держащий его процессор отдать из кэша обратно. И "ворота" здесь равны времени прохождения инструкции через конвейер, после чего кэш-контроллер залочит это слово (если он вообще позволит 2 процессорам модифицировать его одновременно). А как Вы себе это представляете? Особенно интересно применительно к 250ms. VB> Поэтому, к сожалению, функция STLock::unlock() - на всех нормальных VB> системах - VB> уходит в ядро, где и происходит сброс кэшей. А нельзя ли показать место в каком-нибудь ядре, где происходит сброс кэшей? Или хотя бы указать инструкцию x86, которая делает это? Спасибо. :) -- Eugene Berdnikov --- ifmail v.2.15dev5 * Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор Архивное /ru.linux/5353f5118221.html, оценка из 5, голосов 10
|
|
|