Re[15]: ConcurrentDictionary vs reference type
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 21.02.22 16:09
Оценка:
Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, Serginio1, Вы писали:


S>>Неужто и иммутабельные тоже запретить? Почему?


C>При помещении объекта в коллекцию запись данных есть, так что memory read-write reordering. Почему бы тебе не ознакомиться для начала с азами?

Сам то объект не меняется. Какие проблемы. Те же интернированные строки испокон веков лежат себе в коллекциях. https://docs.microsoft.com/ru-ru/dotnet/api/system.string.intern?view=net-5.0
и солнце б утром не вставало, когда бы не было меня
Re[20]: ConcurrentDictionary vs reference type
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 21.02.22 16:15
Оценка:
Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, samius, Вы писали:


S>>Т.е. указания о том, почему так делать можно или нельзя, он почему-то пытается найти в документации библиотечных типов, а не в модели памяти.


C>Объясняю еще раз, для самых сообразительных. Полагаться на модель памяти можно только в том случае, если ConcurrentDictionary гарантированно использует барьер памяти. Ну а ты сам же писал, что полагаться на это нельзя, раз про это не написано в документации. Так что — либо использовать объекты в CD нельзя, либо документацию все же писали кретины.


Ты читал мои ссылки? ConcurrentDictionary для поиска и чтения использует Volatile.Read и lock для цепочки для безопасности записи.
Проблемы с чтением и записью объекта нет, а вот безопасный доступ к свойствам объекта ты уже сам должен позаботиться.
Поэтому у иммутабельных объектов об этом задумываться не надо
и солнце б утром не вставало, когда бы не было меня
Re[8]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 21.02.22 16:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Вы не могли бы проиллюстрировать это утверждение кодом?


Я просто исхожу из утверждений предыдущего оратора.

Все, что гарантирует ConcurrentDictionary, написано в его документации и его гарантии никак не распространяются на все остальное. Если в его значениях ссылки, то словарь гарантирует что ссылка будет приписана к значению. А каким образом там пользователь словаря работает с тем, на что ссылка ссылается — не словаря дело.


Если допустить что это действительно так, то класть объекты в CD нельзя. Нужно объяснять, почему?
Ад пуст, все бесы здесь.
Re[18]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 21.02.22 16:31
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Он стоит меньше чем Lock столько же сколько и Interlocked


Можно использовать только в очень ограниченном числе случаев.
И если использовать volatile в неизменяемом объекте который ты часто читаешь, то это вусмерть убьет производительность.

S>Все используют и вдруг появился Codealot и выбрасывает в утиль.


Тебе напомнить, сколько раз "все" без колебаний делали какую-нибудь хрень? Например, клали CString в %s, если кто-то еще помнит?
Ад пуст, все бесы здесь.
Re[21]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 21.02.22 16:35
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Ты читал мои ссылки? ConcurrentDictionary для поиска и чтения использует Volatile.Read и lock для цепочки для безопасности записи.

S> Проблемы с чтением и записью объекта нет, а вот безопасный доступ к свойствам объекта ты уже сам должен позаботиться.
S>Поэтому у иммутабельных объектов об этом задумываться не надо

Это уже совсем другой поворот. Но предыдущий оратор писал, что полагаться на это нельзя.
Ад пуст, все бесы здесь.
Re[16]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 21.02.22 16:35
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Сам то объект не меняется. Какие проблемы.


Меняется, хотя всего один раз.

S>Те же интернированные строки испокон веков лежат себе в коллекциях. https://docs.microsoft.com/ru-ru/dotnet/api/system.string.intern?view=net-5.0


lock-free коллекциях?
Ад пуст, все бесы здесь.
Re[20]: ConcurrentDictionary vs reference type
От: samius Россия http://sams-tricks.blogspot.com
Дата: 21.02.22 17:24
Оценка: 6 (1) +2 :)
Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, samius, Вы писали:


S>>Т.е. указания о том, почему так делать можно или нельзя, он почему-то пытается найти в документации библиотечных типов, а не в модели памяти.


C>Объясняю еще раз, для самых сообразительных. Полагаться на модель памяти можно только в том случае, если ConcurrentDictionary гарантированно использует барьер памяти.

Вот тут ошибка. Модель памяти — это часть стандарта CLI, на котором построен .NET и C# в частности. И если мы не можем полагаться на модель памяти, то речь не о .NET, C#, а о какой-то поделке. И с этой поделкой в другой форум. Какой именно — не знаю. Может, в философию...
В этом форуме мы обсуждаем ситуации, когда Execution Engine и JIT компиляторы делают все, что бы на модель памяти можно было полагаться. Из этого и исходим далее.


C>Ну а ты сам же писал, что полагаться на это нельзя, раз про это не написано в документации. Так что — либо использовать объекты в CD нельзя, либо документацию все же писали кретины.


Любой способ передачи ссылки на объект, расположенный в куче .NET обеспечивает видимость корректно инициализированного объекта. За это отвечает реализация EE/JIT. Вплоть до размещения барьера памяти внутри конструктора, при необходимости.

S>>И, видимо, об остальных пользователях дотнета такого же мнения.


C>Не забудь добавить, что как мы выяснили, ты ничего не знал про memory read-write reordering, но все равно писал многопоточный код.

Я многого не знаю, и, возможно, не узнаю. Особенно того, что за пределами абстракций и гарантий, которые я использую для работы.
Re[21]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 21.02.22 17:36
Оценка:
Здравствуйте, samius, Вы писали:

S>Вот тут ошибка. Модель памяти — это часть стандарта CLI, на котором построен .NET и C# в частности.


Я вижу, ты мастер переобуться на бегу. Просто процитирую.

Понятно, это на уровне конкретного CPU, и в модели памяти дотнета (и джавы тоже) такого нет.


S>И если мы не можем полагаться на модель памяти, то речь не о .NET, C#, а о какой-то поделке.


Полагаться на модель памяти можно. Но нельзя полагаться на то, чего она не гарантирует.

S>Любой способ передачи ссылки на объект, расположенный в куче .NET обеспечивает видимость корректно инициализированного объекта. За это отвечает реализация EE/JIT.


Ничего подобного она не обеспечивает, и я сам фиксил баги, которые понаделали те кто в это верил. Сами они пофиксить не осилили.

S>Вплоть до размещения барьера памяти внутри конструктора, при необходимости.


А это чертовски интересно. Есть источники?

S>Я многого не знаю, и, возможно, не узнаю. Особенно того, что за пределами абстракций и гарантий, которые я использую для работы.


Для любой многопоточности сложнее чем "делаем lock всегда и на все" это — азы.
Ад пуст, все бесы здесь.
Re[19]: ConcurrentDictionary vs reference type
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 21.02.22 19:56
Оценка:
Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, Serginio1, Вы писали:


S>> Он стоит меньше чем Lock столько же сколько и Interlocked


C>Можно использовать только в очень ограниченном числе случаев.

C>И если использовать volatile в неизменяемом объекте который ты часто читаешь, то это вусмерть убьет производительность.
Ну а как ты хочешь работать в многопотоке?
Твои решения
S>>Все используют и вдруг появился Codealot и выбрасывает в утиль.

C>Тебе напомнить, сколько раз "все" без колебаний делали какую-нибудь хрень? Например, клали CString в %s, если кто-то еще помнит?

Я не плюсовик. Там свои тараканы. В .Net есть другие примеры. Но интересны твои предложения
и солнце б утром не вставало, когда бы не было меня
Re[17]: ConcurrentDictionary vs reference type
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 21.02.22 20:01
Оценка:
Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, Serginio1, Вы писали:


S>>Сам то объект не меняется. Какие проблемы.


C>Меняется, хотя всего один раз.


S>>Те же интернированные строки испокон веков лежат себе в коллекциях. https://docs.microsoft.com/ru-ru/dotnet/api/system.string.intern?view=net-5.0


C>lock-free коллекциях?

Угу и как они защитят от отсутствия Memory Baryer?
Опять же все lock-free основаны на Interlocked, Volatile а он и есть Memory Barrier Lock-free структуры данных. Основы: откуда пошли быть барьеры памяти
и солнце б утром не вставало, когда бы не было меня
Re[17]: ConcurrentDictionary vs reference type
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 21.02.22 20:32
Оценка:
Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, Serginio1, Вы писали:


S>>Сам то объект не меняется. Какие проблемы.


C>Меняется, хотя всего один раз.

Он не меняется, а создается 1 раз в конструкторе!
S>>Те же интернированные строки испокон веков лежат себе в коллекциях. https://docs.microsoft.com/ru-ru/dotnet/api/system.string.intern?view=net-5.0

C>lock-free коллекциях?

Там может и SemaphoreSlim
Но если объектов долго занят то там применяют и Lock и Thread.Sleep и Thread.Yield()
SpinWait
public bool NextSpinWillYield
    {
      [__DynamicallyInvokable] get => this.m_count > 10 || PlatformHelper.IsSingleProcessor;
    }

 public void SpinOnce()
    {
      if (this.NextSpinWillYield)
      {
        CdsSyncEtwBCLProvider.Log.SpinWait_NextSpinWillYield();
        int num = this.m_count >= 10 ? this.m_count - 10 : this.m_count;
        if (num % 20 == 19)
          Thread.Sleep(1);
        else if (num % 5 == 4)
          Thread.Sleep(0);
        else
          Thread.Yield();
      }
      else
        Thread.SpinWait(4 << this.m_count);
      this.m_count = this.m_count == int.MaxValue ? 10 : this.m_count + 1;
    }


 public static bool SpinUntil(Func<bool> condition, int millisecondsTimeout)
    {
      if (millisecondsTimeout < -1)
        throw new ArgumentOutOfRangeException(nameof (millisecondsTimeout), (object) millisecondsTimeout, Environment.GetResourceString("SpinWait_SpinUntil_TimeoutWrong"));
      if (condition == null)
        throw new ArgumentNullException(nameof (condition), Environment.GetResourceString("SpinWait_SpinUntil_ArgumentNull"));
      uint num = 0;
      if (millisecondsTimeout != 0 && millisecondsTimeout != -1)
        num = TimeoutHelper.GetTime();
      SpinWait spinWait = new SpinWait();
      while (!condition())
      {
        if (millisecondsTimeout == 0)
          return false;
        spinWait.SpinOnce();
        if (millisecondsTimeout != -1 && spinWait.NextSpinWillYield && (long) millisecondsTimeout <= (long) (TimeoutHelper.GetTime() - num))
          return false;
      }
      return true;
    }

https://habr.com/ru/post/459514/
и солнце б утром не вставало, когда бы не было меня
Re[20]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 21.02.22 20:37
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Ну а как ты хочешь работать в многопотоке?

S>Твои решения

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

S> Я не плюсовик. Там свои тараканы. В .Net есть другие примеры. Но интересны твои предложения


Это я просто о том, что "все так делают" вообще не аргумент.
Ад пуст, все бесы здесь.
Re[18]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 21.02.22 20:37
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Опять же все lock-free основаны на Interlocked, Volatile а он и есть Memory Barrier Lock-free структуры данных. Основы: откуда пошли быть барьеры памяти


А предыдущий оратор писал, что нельзя на это полагаться. Так какие претензии ко мне тогда?
Ад пуст, все бесы здесь.
Re[18]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 21.02.22 20:37
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Он не меняется, а создается 1 раз в конструкторе!


Это не отменяет необходимости изменить память, где он будет лежать.
Ад пуст, все бесы здесь.
Re[9]: ConcurrentDictionary vs reference type
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 22.02.22 01:34
Оценка: +1
Здравствуйте, Codealot, Вы писали:

C>Если допустить что это действительно так, то класть объекты в CD нельзя. Нужно объяснять, почему?

Да, нужно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[10]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 22.02.22 01:42
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Да, нужно.


Ну например, так звезды сложились что у тебя есть ссылка и нет самого объекта.
Ад пуст, все бесы здесь.
Re[21]: ConcurrentDictionary vs reference type
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 22.02.22 07:06
Оценка: :)
Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, Serginio1, Вы писали:


S>> Ну а как ты хочешь работать в многопотоке?

S>>Твои решения

C>Барьер, в данном случае. Но если он уже вызывается в коллекции, то второй раз не нужно. Но полагаться на то что он там вызывается вроде как нельзя

Нужно. Это касается только коллекции, но не объектов.
За доступ к свойствам объектов отвечаешь ты
Барьеры памяти и неблокирующая синхронизация в .NET
и солнце б утром не вставало, когда бы не было меня
Отредактировано 22.02.2022 7:59 Serginio1 . Предыдущая версия .
Re[19]: ConcurrentDictionary vs reference type
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 22.02.22 07:08
Оценка: +1 :)
Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, Serginio1, Вы писали:


S>> Опять же все lock-free основаны на Interlocked, Volatile а он и есть Memory Barrier Lock-free структуры данных. Основы: откуда пошли быть барьеры памяти


C>А предыдущий оратор писал, что нельзя на это полагаться. Так какие претензии ко мне тогда?

Нельзя полагаться на что? За доступ к свойствам объекта из многопотока отвечаешь ты
и солнце б утром не вставало, когда бы не было меня
Re[19]: ConcurrentDictionary vs reference type
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 22.02.22 07:10
Оценка: +1
Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, Serginio1, Вы писали:


S>>Он не меняется, а создается 1 раз в конструкторе!


C>Это не отменяет необходимости изменить память, где он будет лежать.

Нет не надо. Ибо свойства то не меняются и по барабану где лежит ссылка и объектные свойства в регистре, кэше или памяти!
и солнце б утром не вставало, когда бы не было меня
Re[11]: ConcurrentDictionary vs reference type
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 22.02.22 07:12
Оценка: +2
Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, Sinclair, Вы писали:


S>>Да, нужно.


C>Ну например, так звезды сложились что у тебя есть ссылка и нет самого объекта.

Такого не может быть ибо за ссылку и объект отвечает GC. Есть WeakReference но сам то WeakReference существует.
и солнце б утром не вставало, когда бы не было меня
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.