powered by simpleCommunicator - 2.0.55     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / по поводу тормозов lock
25 сообщений из 33, страница 1 из 2
по поводу тормозов lock
    #38782316
netivan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
случайно мне тут попалась статья на мсдн про spinlock http://msdn.microsoft.com/ru-ru/library/dd460716(v=vs.110).aspx
дай думаю быстро наколбашу тестик и посмотрю как все стало круто и быстро. Да и добавлю еще concurrentcollection. Вообщем, товарищи, я расстроился.
тест тут:
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
internal class SpinLockDemo2
    {
        private const int N = 10000000;
        private static Queue<Data> _queue = new Queue<Data>();
        static ConcurrentQueue<Data> _concurrentQueue = new ConcurrentQueue<Data>();
        private static object _lock = new Object();
        private static SpinLock _spinlock = new SpinLock();

        private class Data
        {
            public string Name { get; set; }
            public double Number { get; set; }
        }

        public static void Start(string[] args)
        {
            UseLock();
            _queue = new Queue<Data>();
            GC.Collect();
            GC.WaitForFullGCComplete();
            GC.Collect();
            UseSpinLock();
            GC.Collect();
            GC.WaitForFullGCComplete();
            GC.Collect();
            UseConcurrentLock();

            Console.WriteLine("Press a key");
            Console.ReadKey();
        }

        private static void UpdateWithSpinLock(Data d, int i)
        {
            bool lockTaken = false;
            try
            {
                _spinlock.Enter(ref lockTaken);
                _queue.Enqueue(d);
            }
            finally
            {
                if (lockTaken) _spinlock.Exit(false);
            }
        }

        private static void UseSpinLock()
        {

            Stopwatch sw = Stopwatch.StartNew();

            Parallel.For(1, 4,
                         i2 =>
                             {
                                 for (int i = 0; i < N; i++)
                                 {
                                     UpdateWithSpinLock(new Data() {Name = i.ToString(), Number = i}, i);
                                 }
                             });
                
            sw.Stop();
            Console.WriteLine("elapsed ms with spinlock: {0}", sw.ElapsedMilliseconds);
        }

        private static void UpdateWithLock(Data d, int i)
        {
            lock (_lock)
            {
                _queue.Enqueue(d);
            }
        }
        private static void UpdateConcurrent(Data d, int i)
        {
           _concurrentQueue.Enqueue(d);
        }
        private static void UseLock()
        {
            Stopwatch sw = Stopwatch.StartNew();
            Parallel.For(1, 4,
                                   i2 =>
                                   {
                                       for (int i = 0; i < N; i++)
                                       {
                                           UpdateWithLock(new Data() { Name = i.ToString(), Number = i }, i);
                                       }
                                   });
            sw.Stop();
            Console.WriteLine("elapsed ms with lock: {0}", sw.ElapsedMilliseconds);
        }
        private static void UseConcurrentLock()
        {
            Stopwatch sw = Stopwatch.StartNew();
            Parallel.For(1, 4,
                                   i2 =>
                                   {
                                       for (int i = 0; i < N; i++)
                                       {
                                           UpdateConcurrent(new Data() { Name = i.ToString(), Number = i }, i);
                                       }
                                   });
            sw.Stop();
            Console.WriteLine("elapsed ms with concurrent: {0}", sw.ElapsedMilliseconds);
        }

    }


результат у меня такой:
авторelapsed ms with lock: 7482
elapsed ms with spinlock: 6795
elapsed ms with concurrent: 7830
Press a key
и это при диком колбасе в 10000000 итераций. "я думал лучше будет". Обсудите.
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38782498
cdtyjv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
netivan ,
А что тут обсуждать? Ваш бенчмарк надо срочно выкинуть на помойку, и никому никогда не показывать, так как он некорректен, и сравнивает теплое с мягким. Почитайте на досуге про трудности написания микробенчмарков.
Если вкратце, то вы сейчас измеряете не скорость работы локов, а скорость пута в очередь, скорость боксинга, и скорость ToString().
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38782506
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А чего обсуждать то? Запускаете таски, значит уже детерминированное время. Да и всего 4 конкурирующих потока - маловато.

Попробуйте еще через Interlocked.Exchange:

СТАРТ:
Код: c#
1.
2.
3.
            // стартуем с одновременным измененем флага
            if (Interlocked.CompareExchange(ref fThreadFlag, 1, 0) == 0)
                fThread.Start();



СТОП:
Код: c#
1.
2.
3.
            // стопаем с одновременным измененем флага
            if (Interlocked.CompareExchange(ref fThreadFlag, 0, 1) == 1)
                _exitBytimeout = !fThread.Join(JoinTimeout);



В ТЕЛЕ ПОТОКА:
Код: c#
1.
2.
3.
4.
5.
6.
            // в цикле осуществляется вызов бизнес-функции 
            while (Interlocked.CompareExchange(ref fThreadFlag, 0, 0) == 1)
            {
                if (_isAllowed())
                    PWorkFunction();
            }
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38782513
netivan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79А чего обсуждать то? Запускаете таски, значит уже детерминированное время. Да и всего 4 конкурирующих потока - маловато.

Попробуйте еще через Interlocked.Exchange:

СТАРТ:
Код: c#
1.
2.
3.
            // стартуем с одновременным измененем флага
            if (Interlocked.CompareExchange(ref fThreadFlag, 1, 0) == 0)
                fThread.Start();



СТОП:
Код: c#
1.
2.
3.
            // стопаем с одновременным измененем флага
            if (Interlocked.CompareExchange(ref fThreadFlag, 0, 1) == 1)
                _exitBytimeout = !fThread.Join(JoinTimeout);



В ТЕЛЕ ПОТОКА:
Код: c#
1.
2.
3.
4.
5.
6.
            // в цикле осуществляется вызов бизнес-функции 
            while (Interlocked.CompareExchange(ref fThreadFlag, 0, 0) == 1)
            {
                if (_isAllowed())
                    PWorkFunction();
            }


не то чтобы обсуждать, а просто принимать во внимание,что посты "лок тормозит" смешны. И не кидаться все переписывать. Т.к. весьма сомнительный выигрыш. Через Интрлок сегодня добавлю.
авторА что тут обсуждать? Ваш бенчмарк надо срочно выкинуть на помойку, и никому никогда не показывать, так как он некорректен, и сравнивает теплое с мягким. Почитайте на досуге про трудности написания микробенчмарков.
Если вкратце, то вы сейчас измеряете не скорость работы локов, а скорость пута в очередь, скорость боксинга, и скорость ToString().
я измеряю относительную скорость.
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38782523
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
netivanне то чтобы обсуждать, а просто принимать во внимание,что посты "лок тормозит" смешны. И не кидаться все переписывать. Т.к. весьма сомнительный выигрыш. Через Интрлок сегодня добавлю.
Вообще в вашем тесте нет нелоковых вариантов. concurrent* коллекции сплошь заполнены volatile полями, что означает постоянные обращения к оперативке для синхронизации значений. То есть это УЖЕ не быстро, особенно если подобных обращений миллионы.

Идеальным был бы код вообще без локов и какой либо синхронизации. Данные размещаешь в стэк, компилятор удачно раскидывает их по регистрам процессора, потоки автономно крутятся на процессоре, все очень быстро.

PS Interlocked гарантирует атомарное обращение к полю класса, а не блокировку участка кода. Вам придется помучаться с ним, чтобы синтетический тест сделать адекватным.
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38782572
netivan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79netivanне то чтобы обсуждать, а просто принимать во внимание,что посты "лок тормозит" смешны. И не кидаться все переписывать. Т.к. весьма сомнительный выигрыш. Через Интрлок сегодня добавлю.
Вообще в вашем тесте нет нелоковых вариантов. concurrent* коллекции сплошь заполнены volatile полями, что означает постоянные обращения к оперативке для синхронизации значений. То есть это УЖЕ не быстро, особенно если подобных обращений миллионы.

Идеальным был бы код вообще без локов и какой либо синхронизации. Данные размещаешь в стэк, компилятор удачно раскидывает их по регистрам процессора, потоки автономно крутятся на процессоре, все очень быстро.

PS Interlocked гарантирует атомарное обращение к полю класса, а не блокировку участка кода. Вам придется помучаться с ним, чтобы синтетический тест сделать адекватным.
ну тут сравнение стандартных блокирующих конструкций и slim вариантов. Режим ядра против пользовательского (вроде бы так это называется).
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38782581
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
netivanпропущено...
ну тут сравнение стандартных блокирующих конструкций и slim вариантов. Режим ядра против пользовательского (вроде бы так это называется).

Я всегда считал, что lock - это критическая секция, и она легковесная. Если интересна синхронизация уровня ядра, используйте Mutex либо именованный Event.
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38782659
netivan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79netivanпропущено...
ну тут сравнение стандартных блокирующих конструкций и slim вариантов. Режим ядра против пользовательского (вроде бы так это называется).

Я всегда считал, что lock - это критическая секция, и она легковесная. Если интересна синхронизация уровня ядра, используйте Mutex либо именованный Event.
с Net 4. втирают при гибридные конструкции, которые обеспечивают супер производительность :)
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38782700
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
netivanс Net 4. втирают при гибридные конструкции, которые обеспечивают супер производительность :)
Если речь об этом: http://habrahabr.ru/post/91027/, то не совсем. Суперпроизводительность будет только в том случае, если реального ожидания не будет. Про Interlocked я выше упоминал, он действительно шустрый. Собственно, легковесная spin-блокировка на его основе - это достойная альтернатива lock-у.

В куске моего кода есть _isAllowed(), там как раз и сделан timeout. Объясню, почему sleep делается всегда на 1 - чтобы поток был отзывчивым, и смог завершить свою работу, даже когда он "спит" (-1 - никакого ожидания, связанного с переключением контекста, нет). Обращаю внимание, что мой код не предназначен для работы в многопоточной среде. У него немного другая функциональность. Я его привел для иллюстрации варианта альтернативы Monitor.Enter - while + Interlocked + Sleep:
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
            Func<bool> _isAllowed =
                () =>
                    {
                        DateTime _now = DateTime.Now;

                        bool _result = (MinimalIterationTimeout == -1 || (_now - _lastExecuted).TotalMilliseconds > MinimalIterationTimeout);

                        if (_result)
                            _lastExecuted = _now;

                        // Допустим и 0, то тогда в диспетчере будет показываться 100% 
                        // загрузка. При этом приложение будет отзываться
                        // 1 идентична интервалу в 16
                        if (MinimalIterationTimeout != -1)
                            Thread.Sleep(1);

                        return _result;
                    };



Но в случае конкуренции все равно будет обращение к ядру, что сравнительно тяжело. В общем, для синхронизации потоков в одном процессе применение объектов уровня ядра нецелесообразно, ввиду излишних временнЫх затрат. Если речь не идет о наносекундах, пользуйте lock и не парьтесь.
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38782720
netivan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79,

автор Если речь не идет о наносекундах, пользуйте lock и не парьтесь.
примерно это и хотел сказать/ показать. Все равно вечером добавлю вариант с Interlocked.
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38782728
netivan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
netivanArm79,

автор Если речь не идет о наносекундах, пользуйте lock и не парьтесь.
примерно это и хотел сказать/ показать. Все равно вечером добавлю вариант с Interlocked.
хотя вот тут http://habrahabr.ru/post/91027/ разница заметна. Но ведь WaitHandle это объект ядра Windows если я правильно помню. Так что надо попробывать еще сравнить Mutex vs SlimMutex Ж)
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38783292
cdtyjv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79netivanне то чтобы обсуждать, а просто принимать во внимание,что посты "лок тормозит" смешны. И не кидаться все переписывать. Т.к. весьма сомнительный выигрыш. Через Интрлок сегодня добавлю.
Вообще в вашем тесте нет нелоковых вариантов. concurrent* коллекции сплошь заполнены volatile полями, что означает постоянные обращения к оперативке для синхронизации значений. То есть это УЖЕ не быстро, особенно если подобных обращений миллионы.

Идеальным был бы код вообще без локов и какой либо синхронизации. Данные размещаешь в стэк, компилятор удачно раскидывает их по регистрам процессора, потоки автономно крутятся на процессоре, все очень быстро.

PS Interlocked гарантирует атомарное обращение к полю класса, а не блокировку участка кода. Вам придется помучаться с ним, чтобы синтетический тест сделать адекватным.Я же вам вроде объяснял, что volatile не означает, что каждое обращение лезет именно в оперативу, не?
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38783334
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cdtyjvЯ же вам вроде объяснял, что volatile не означает, что каждое обращение лезет именно в оперативу, не?
1) Если хочется пообщаться конкретно со мной, пишите на почту
2) Если речь идет о демонстрации своих знаний/исправлении неточностей в предыдущих комментах - нужно писать более подробно, с указанием места ошибки/неточности

Мы в прошлый раз договорились до того, что отнюдь не во всех случаях volatile нужен. Во многих - можно прекрасно обойтись и без него. Более того, не самая простая концепция этого volatile (+ограничение по доступным типам) провоцирует ошибки. Нужно быть проще - использовать concurrent-коллекции или банальный lock.

Теперь что касается оперативки. У вас есть данные, отрицающие, что распространение изменений, внесенных в кэш на одном процессоре, на другие происходит через оперативную память?
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38783381
cdtyjv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79,
Гуглите по фразе cache snooping
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38783393
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cdtyjvArm79,
Гуглите по фразе cache snooping

Давайте не будем углубляться в гугление. Там много мусора всплыло, разбираться дорого. Вы сразу ссылку на наиболее адекватное изложение материала дайте
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38783394
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cdtyjvArm79,
Гуглите по фразе cache snooping

Давайте не будем углубляться в гугление. Там много мусора всплыло, разбираться дорого. Вы сразу ссылку на наиболее адекватное изложение материала дайте
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38783425
cdtyjv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79Давайте не будем углубляться в гугление. Там много мусора всплыло, разбираться дорого. Вы сразу ссылку на наиболее адекватное изложение материала дайтеЕсли вы не будете углубляться, то так и не разберетесь в архитектуре компьютеров.
Предположите следующую ситуацию. У вас есть два процессора, два кэша. Первый процессор запрашивает адрес A, к которому никто раньше не обращался. Ему приходится идти в память, которая находится на другом конце материнской платы. Через какое-то время второй процессор так же запрашивает адрес А.
Как вы думаете, можно ли реализовать такую оптимизацию, что если процессору 2 нужен адрес, который уже есть в процессоре 1, то вместо того, что бы идти в память, можно получить значение из кэша процессора 1?
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38783499
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cdtyjvArm79Давайте не будем углубляться в гугление. Там много мусора всплыло, разбираться дорого. Вы сразу ссылку на наиболее адекватное изложение материала дайтеЕсли вы не будете углубляться, то так и не разберетесь в архитектуре компьютеров.
Предположите следующую ситуацию. У вас есть два процессора, два кэша. Первый процессор запрашивает адрес A, к которому никто раньше не обращался. Ему приходится идти в память, которая находится на другом конце материнской платы. Через какое-то время второй процессор так же запрашивает адрес А.
Как вы думаете, можно ли реализовать такую оптимизацию, что если процессору 2 нужен адрес, который уже есть в процессоре 1, то вместо того, что бы идти в память, можно получить значение из кэша процессора 1?

Давайте вы свой поучительный тон оставите для студентов вашего курса? Эти намеки и прочее только раздражают. Вы либо кидаете ссылку, где это обстоятельно рассказывают, либо рассказываете сами.
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38783510
cdtyjv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79 ,
То есть, разбираться самостоятельно вы не хотите, хотя я привел вам название механизма, который это реализует. Ну вот вам статейка, например: http://www.realworldtech.com/common-system-interface/5/
Но она уже достаточно специализирована. Надо начинать с азов - как в принципе устроен кэш, что такое MESI, что такое store forwarding, store buffer, invalidate queue, NUMA, и т.д..
Ключевая выдержка из статьи:
авторIntel’s solution to this issue is rather elegant. They adapted the standard MESI protocol to include an additional state, the Forwarding (F) state, and changed the role of the Shared (S) state. In the MESIF protocol, only a single instance of a cache line may be in the F state and that instance is the only one that may be duplicated [3]. Other caches may hold the data, but it will be in the shared state and cannot be copied. In other words, the cache line in the F state is used to respond to any read requests , while the S state cache lines are now silent. This makes the line in the F state a first amongst equals, when responding to snoop requests. By designating a single cache line to respond to requests, coherency traffic is substantially reduced when multiple copies of the data exist.
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38783517
netivan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Зачем топик засрали? Память в отдельной ветке можно обсуждать
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38783518
cdtyjv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На пальцах это выглядит примерно так. Предположим, что у нас есть два процессора. Когда первый процессор запрашивает адрес А, он должен отправить куда-то запрос на это. Куда? В шину данных. А шину данных одновременно слушает и оперативка, и кэш второго процессора. Поэтому, когда первый кэш отправит запрос на чтение A, этот запрос придет и во второй кэш. И этот второй кэш ответит первому значительно быстрее, чем медленная оператива. Вот и вся магия.
Как на это влияет volatile? Никак, на уровне железа понятия volatile нет. Там есть специальные команды синхронизации кэшей, вроде префикса "lock" на x86. Но что бы понять, как эта синхронизация работает, вам надо понимать работу MESI, а вы не хотите "углубляться" во все это. Так вот, volatile, что в .Net, что в Java, работает одинаково:
1) Он запрещает оптимизации доступа к переменной на уровне JIT-компилятора.
2) Он добавляет инструкции синхронизации кэшей вокруг этих переменных. Например, в Java на x86 это инструкция "lock addl(0, esp)" - то есть прибаление нуля к значению текущего указателя стэка. Сама по себе операция смысла не имеет, но префикс lock запрещает процессору заниматься спекуляциями в окресностях этой команды, а так же заставляет предыдущие записи, сидящие в store buffer, синхронизироваться с кэшами других процессоров.
Ну да ладно, это дебри уже. Важно понимать, что volatile сам по себе никак не может влиять на то, откуда будет прочитано значение переменной - из кэша текущего процессора, кэша другого процессора, или из оперативы. Это зависит только от того, что (и в каком состоянии) сейчас находится в кэшах процессора.
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38783519
cdtyjv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
netivanЗачем топик засрали? Память в отдельной ветке можно обсуждатьНу дак с вашей темой мы же разобрались уже - там бенчмарки некорректные, нет предмета обсуждения.
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38783524
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cdtyjvНа пальцах это выглядит примерно так. Предположим, что у нас есть два процессора. Когда первый процессор запрашивает адрес А, он должен отправить куда-то запрос на это. Куда? В шину данных. А шину данных одновременно слушает и оперативка, и кэш второго процессора. Поэтому, когда первый кэш отправит запрос на чтение A, этот запрос придет и во второй кэш. И этот второй кэш ответит первому значительно быстрее, чем медленная оператива. Вот и вся магия.
Как на это влияет volatile? Никак, на уровне железа понятия volatile нет. Там есть специальные команды синхронизации кэшей, вроде префикса "lock" на x86. Но что бы понять, как эта синхронизация работает, вам надо понимать работу MESI, а вы не хотите "углубляться" во все это. Так вот, volatile, что в .Net, что в Java, работает одинаково:
1) Он запрещает оптимизации доступа к переменной на уровне JIT-компилятора.
2) Он добавляет инструкции синхронизации кэшей вокруг этих переменных. Например, в Java на x86 это инструкция "lock addl(0, esp)" - то есть прибаление нуля к значению текущего указателя стэка. Сама по себе операция смысла не имеет, но префикс lock запрещает процессору заниматься спекуляциями в окресностях этой команды, а так же заставляет предыдущие записи, сидящие в store buffer, синхронизироваться с кэшами других процессоров.
Ну да ладно, это дебри уже. Важно понимать, что volatile сам по себе никак не может влиять на то, откуда будет прочитано значение переменной - из кэша текущего процессора, кэша другого процессора, или из оперативы. Это зависит только от того, что (и в каком состоянии) сейчас находится в кэшах процессора.

Не успел ответить до этого сообщения. Неужели трудно было в двух словах сказать - существуют протоколы когерентности кэшей (например, MESI), согласно которым кэши могут обмениваться информацией вне оперативки? Зачем были эти ненужные сообщения?

Будем считать, что вы уточнили мое сообщение, что не только через оперативку, заодно просветили меня по поводу аппаратной части.

Что касается
cdtyjvЕсли вы не будете углубляться, то так и не разберетесь в архитектуре компьютеров.
то мне это уже не нужно, я закончил (по крайней мере как с основным источником дохода) с программированием в 2013 году. Теперь это хобби :-) Ну и фриланс совсем помаленечку, чтобы не забывать
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38783531
cdtyjv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79Не успел ответить до этого сообщения. Неужели трудно было в двух словах сказать - существуют протоколы когерентности кэшей (например, MESI), согласно которым кэши могут обмениваться информацией вне оперативки? Зачем были эти ненужные сообщения?Елы палы:
1) Открыть Гугл;
2) Вбить "cache snooping", как я и предлагал;
3) Открыть первый результат: http://en.wikipedia.org/wiki/Bus_sniffing
4) Прочитать первую строчку: "Bus sniffing or Bus snooping is a technique used in distributed shared memory systems and multiprocessors to achieve cache coherence ."

Я же не знал, что вы настолько ленивый :-)
...
Рейтинг: 0 / 0
по поводу тормозов lock
    #38783673
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cdtyjvЯ же не знал, что вы настолько ленивый :-)
Еще бы, ведь там еще и переводить с английского надо :-) Зачем это делать, когда есть вы
...
Рейтинг: 0 / 0
25 сообщений из 33, страница 1 из 2
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / по поводу тормозов lock
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]