 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Valentin Nechayev 2:5020/400 12 Mar 2001 19:25:20 To : Vladimir Butenko Subject : Re: Microsoft предлагает запретить Linux!!! -------------------------------------------------------------------------------- >>> Vladimir Butenko wrote: >> А вот зачем писать под локом, когда пишет только один тред, и читать без >> лока - уже непонятно. Если бы там было сложнее одного числа в одном >> машинном слове, то надо reader/writer locks. VB> Так я потому и написал - "пояснять?". Фишка в том, что на многопроцессорной VB> машине никто Вам не гарантирует, что при выполнении: VB> a : int := 0; VB> thread1: VB> а := 1; VB> ..... VB> thread2: VB> b := a; VB> в b попадет именно 1 ДАЖЕ ЕСЛИ ВЫ ПОЛHОСТЬЮ УВЕРЕHЫ, что в VB> оператор во втором треде выполнится позже. Причина - в кэшах процессоров, VB> который вовсе не обязаны сбрасывать все в память сразу, а также инвалидить VB> кэш других процессоров при каждой записи в память. Инвалидить весь кэш и не надо. А вот наблюдение за шиной и прочистка одиночных записей, соответствующих пробежавшему по шине - AFAIR, производится у всех. Поправьте, если неправ. VB> Поэтому, к сожалению, функция STLock::unlock() - на всех нормальных VB> системах - VB> уходит в ядро, где и происходит сброс кэшей. (К нормальным не относятся VB> сейчас Free/OpenBSD, где треды - чисто узверные, а потому - работают VB> по определению всегда на одном процессоре). VB> Вот поэтому приходится обрамлять локом - который ничего не лочит, VB> а просто гарантирует синхроницазию кэшей. В Форточках на двух-процесорном Гарантирует на каком железе? Вот согласно линуховым сорцам: === cut include/asm-i386/memory.h === /* * Force strict CPU ordering. * And yes, this is required on UP too when we're talking * to devices. * * For now, "wmb()" doesn't actually do anything, as all * Intel CPU's follow what Intel calls a *Processor Order*, * in which all writes are seen in the program order even * outside the CPU. * * I expect future Intel CPU's to have a weaker ordering, * but I'd also expect them to finally get their act together * and add some real memory barriers if so. */ #define mb() __asm__ __volatile__ ("lock; addl $0,0(%%esp)": : :"memory") #define rmb() mb() #define wmb() __asm__ __volatile__ ("": : :"memory") === end cut === то есть - на x86, write memory barrier отсутствует и вы тут ничего не получаете именно для той цели, которую описали, разве что наоборот. Hа другом железе - да, там чаще всего какие-то явные команды. Hо на x86 ничего кроме бесполезной траты ресурсов этим не получите. Hо, на самом деле, речь идет о наносекундах. Я не вижу смысла стараться ради этого, если это не собственно межпроцессорная синхронизация. VB> писюке - без локов очень хорошо видно, как возникает такая ситуация, если VB> не ставить локов. А это не что-то иное? >> VB> STGMTNonExact() - >> VB> просто берет значение из этой глобальной переменной (без локов). >> Угу, схема известная (phk такое во фревое ядро позагонял). VB> А что тогда спрашиваете :-)? А вдруг еще какой-то вариант на самом деле применен ;) /netch --- ifmail v.2.15dev5 * Origin: Lucky Netch Incorporated (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор Архивное /ru.linux/9138755ee3cd.html, оценка из 5, голосов 10
|
|
|