 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Vladimir Butenko 2:5020/400 13 Mar 2001 04:45:48 To : All Subject : Re: Microsoft предлагает запретить Linux!!! -------------------------------------------------------------------------------- Valentin Nechayev <netch@segfault.kiev.ua> wrote in message news:98ipo9$vbd$1@news.lucky.net... > >>> 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, производится > у всех. Поправьте, если неправ. А какая-такая шина? А если у меня процессор такой, что у него не write-through запись, и он модифицированное в кэше хранит, и в основную память (и, соответственно, на шину) писанет это хрен знает когда. Так что - все очень сильно от процессора и его кэшей зависит. Hа Интелях как раз в этой области всегда были полные дрова, потому и скалируются они фиговатенько-фиговатенько - в SMP. Hо сейчас, вроде, получше стало. > то есть - на x86, write memory barrier отсутствует и вы тут ничего не > получаете именно для той цели, которую описали, разве что наоборот. Я же Вам говорю факт из жизни - на Форточках, на двухпроцессорной фигне, необвязка локами приводит к тому, что другой тред может и не увидеть измененного данного в памяти. Что там в каком-то Линухе - понятия не имею. Как с многопроцессорностью в Интеле обстоят дела СЕЙЧАС, и как именно Форточки работают с тем же Xeon'-ами - мне не ведомо. Ведомо то, что приведенная конструкция (обвязка локами) гарантирует требуемые свойства. Hа любой платформе, которая работает. > Hа другом железе - да, там чаще всего какие-то явные команды. Hо на x86 > ничего кроме бесполезной траты ресурсов этим не получите. Угу. Я бы поверил. А траты ресурсов нету - один вызов unlock в четверть секунды - это вообще не считается. То Вы легко предлагаете какие-то лишние командочки в сокеты сувать (а это как раз - реальные перерасход), то Вас интересует 8 лишних сыскала в секунду (это сколько сотых процента?) > Hо, на самом деле, речь идет о наносекундах. Я не вижу смысла стараться > ради этого, если это не собственно межпроцессорная синхронизация. Hет. Если этого не делать, то у тредов башка поедет - время будет не монотонное, как у того попугая из "Понедельника". В зависимости от того, на какой процессор тред попадет - у него будет плюс-минус секунда, а то и пара. > VB> писюке - без локов очень хорошо видно, как возникает такая ситуация, если > VB> не ставить локов. > > А это не что-то иное? Hе-а. Hаука - она штука забавная. Только игнорируешь - сразу по балде бьет. > /netch Вова --- ifmail v.2.15dev5 * Origin: Gamma NNTP server Moscow Russia (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор Архивное /ru.linux/759140ff15fa.html, оценка из 5, голосов 10
|
|
|