Re[36]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 07.03.22 20:57
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Сказано, же что блокировка не на всю таблицу, а только на hash % размер таблицы.


В любом случае, на каждую операцию она не вызывается.

S> Там проблема не в барьере памяти. В любом случае нет проблем с неизменяемыми объектами нет.


Есть. Re[34]: ConcurrentDictionary vs reference type
Автор: Codealot
Дата: 07.03 22:51
Ад пуст, все бесы здесь.
Re[37]: ConcurrentDictionary vs reference type
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 07.03.22 21:24
Оценка:
Здравствуйте, Codealot, Вы писали:

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


S>> Сказано, же что блокировка не на всю таблицу, а только на hash % размер таблицы.


C>В любом случае, на каждую операцию она не вызывается.

Не на каждую, а на вставку. Ну посмотри исходники. Для чтения там барьер памяти. Но ты то утверждаешь, что проблемы в объектах и ConcurrentDictionary должны обеспечивать их модификацию.
S>> Там проблема не в барьере памяти. В любом случае нет проблем с неизменяемыми объектами нет.

C>Есть. Re[34]: ConcurrentDictionary vs reference type
Автор: Codealot
Дата: 07.03 22:51


Это пример того как выстреливать себе в ногу. Как я уже приводил пример тебе.
Здесь идет захват переменной в замыкании. Там вообще отдельный класс. Это вообще другая опера.
И поле в твоем примере не readonly. Private, но изменяемое внутри объекта. Какой же оно неизменяемое?
Если ты можешь менять поле внутри объекта, то позаботься о volatile различными способами
и солнце б утром не вставало, когда бы не было меня
Re[38]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 07.03.22 21:34
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Но ты то утверждаешь, что проблемы в объектах и ConcurrentDictionary должны обеспечивать их модификацию.


ЩИТО?

S> Это пример того как выстреливать себе в ногу. Как я уже приводил пример тебе.

S>Здесь идет захват переменной в замыкании. Там вообще отдельный класс. Это вообще другая опера.

Ты бредишь. Где ты там нашел замыкание?
Ад пуст, все бесы здесь.
Re[39]: ConcurrentDictionary vs reference type
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.03.22 07:55
Оценка:
Здравствуйте, Codealot, Вы писали:

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


S>>Но ты то утверждаешь, что проблемы в объектах и ConcurrentDictionary должны обеспечивать их модификацию.


C>ЩИТО?


S>> Это пример того как выстреливать себе в ногу. Как я уже приводил пример тебе.

S>>Здесь идет захват переменной в замыкании. Там вообще отдельный класс. Это вообще другая опера.

C>Ты бредишь. Где ты там нашел замыкание?

Вот здесь по ссылке https://docs.microsoft.com/en-us/archive/msdn-magazine/2013/january/csharp-the-csharp-memory-model-in-theory-and-practice-part-2#compiler-optimizations
Что касается твоей ссылки https://docs.microsoft.com/en-us/archive/msdn-magazine/2013/january/csharp-the-csharp-memory-model-in-theory-and-practice-part-2#example-lazy-initialization

Опять же там нет никаких readonly полей. Но ты же утверждаешь, что есть проблемы с неизменяемыми объектами

Там проблема не в барьере памяти. В любом случае нет проблем с неизменяемыми объектами нет.


Но ты утверждаешь, что есть и даешь ссылку http://rsdn.org/forum/message/8224254.1
Автор: Codealot
Дата: 07.03 22:51

Но никаких readonly полей там нет!
и солнце б утром не вставало, когда бы не было меня
Re[40]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 08.03.22 16:11
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Вот здесь по ссылке


Это всего лишь один пример. Речь идет про операции с памятью вообще.

As mentioned in the first article, the compiler might optimize the code in a way that reorders memory operations.


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


readonly важно только в том случае, если ты собираешься менять объекты которые уже созданы и используются другими тредами. Memory reordering будет и если он есть, и если его нет.

S>Но никаких readonly полей там нет!


Ты вообще не понимаешь, о чем идет речь. Услышал звон, да не понял где он.
Ад пуст, все бесы здесь.
Re[25]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 08.03.22 16:23
Оценка:
Здравствуйте, ·, Вы писали:

·>Твоё заявление: "CIL generators должны нам обеспечить 42", неверно, это ошибка. Ничего в стандарте 42 не обеспечивает, только текущие детали имплементации платформы от microsoft это обещают.


So, the CLR JIT makes an extra effort (beyond what’s mandated in the ECMA C# spec) to keep the most common variant of incorrect lazy initialization working on ARM.

Охохо.
Ад пуст, все бесы здесь.
Re[41]: ConcurrentDictionary vs reference type
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.03.22 16:29
Оценка:
Здравствуйте, Codealot, Вы писали:

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


S>> Вот здесь по ссылке


C>Это всего лишь один пример. Речь идет про операции с памятью вообще.

C>

C>As mentioned in the first article, the compiler might optimize the code in a way that reorders memory operations.


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


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

readonly важно тем, что инициализируешь только в конструкторе. И они потокобезопасны! Их нельзя менять!
А в однопоточном конструкторе глубоко наплевать на Memory reordering!

Я тебе привел примеры классов которые можно безопасно использовать в ConcurrentDictionary

S>>Но никаких readonly полей там нет!


C>Ты вообще не понимаешь, о чем идет речь. Услышал звон, да не понял где он.


Приведи пример. Тебя вообще мало кто понимает.

Ответь на вопрос

Там проблема не в барьере памяти. В любом случае нет проблем с неизменяемыми объектами нет.



Но ты утверждаешь, что есть и даешь ссылку http://rsdn.org/forum/message/8224254.1
Автор: Codealot
Дата: 07.03 22:51
и солнце б утром не вставало, когда бы не было меня
Re[42]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 08.03.22 16:39
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>readonly важно тем, что инициализируешь только в конструкторе. И они потокобезопасны! Их нельзя менять!

S>А в однопоточном конструкторе глубоко наплевать на Memory reordering!

До тебя так и не дошло, что компилятор, рантайм и платформа могут произвольно менять порядок операций с памятью, если это ничего не ломает в данном конкретном треде? readonly, не readonly — вообще неважно.

S> Приведи пример. Тебя вообще мало кто понимает.


Топик такой, что его вообще крайне мало кто понимает. Хотя тех, кто думает что понимает — очень много.
Ад пуст, все бесы здесь.
Re[43]: ConcurrentDictionary vs reference type
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.03.22 16:50
Оценка: :)
Здравствуйте, Codealot, Вы писали:

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


S>>readonly важно тем, что инициализируешь только в конструкторе. И они потокобезопасны! Их нельзя менять!

S>>А в однопоточном конструкторе глубоко наплевать на Memory reordering!

C>До тебя так и не дошло, что компилятор, рантайм и платформа могут произвольно менять порядок операций с памятью, если это ничего не ломает в данном конкретном треде? readonly, не readonly — вообще неважно.

Ну и меняют они в конструкторе. Объясни в чем проблема?
S>> Приведи пример. Тебя вообще мало кто понимает.

C>Топик такой, что его вообще крайне мало кто понимает. Хотя тех, кто думает что понимает — очень много.

Угу тебе уже кучу доводов привели. И про voliatil написали. Но у тебя какие то тараканы в голове и мешанина.
Ты так и не привел примера

ConcurrentDictionary гарантирует безопасность объектов (если исходить из предположения, что они read-only), или нужны какие-то дополнительные движения с бубном?
Документация чего-то не рассматривает этот вопрос


ConcurrentDictionary гарантирует потокобезопасное запись и чтение из словаря. Потокобезопасность объекта ты должен обеспечить сам!
и солнце б утром не вставало, когда бы не было меня
Re[44]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 08.03.22 16:58
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Ну и меняют они в конструкторе. Объясни в чем проблема?



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

S> Угу тебе уже кучу доводов привели. И про voliatil написали. Но у тебя какие то тараканы в голове и мешанина.


Не у меня.
Вот тебе конкретный пример:
// Warning: Bad code
class LazyExample
{
  private BoxedInt _boxedInt; // Note: This field is not volatile
  int GetInt()
  {
    BoxedInt b = _boxedInt; // Read 1
    if (b == null)
    {
      b = new BoxedInt(42); // Write 1 (inside constructor)
      _boxedInt = b;        // Write 2
    }
    return b._value;        // Read 2
  }
}


Обрати внимание — поле в BoxedInt присваивается только в конструкторе.
Ад пуст, все бесы здесь.
Re[45]: ConcurrentDictionary vs reference type
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.03.22 17:07
Оценка:
Здравствуйте, Codealot, Вы писали:

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


S>> Ну и меняют они в конструкторе. Объясни в чем проблема?


C>

C>Меняют вообще в любой момент, когда им захочется.
C>До тебя не доходит, что такие перестановки могу привести к тому, что с точки зрения другого треда ссылка на объект будет доступна раньше записей, который его инициализируют?

S>> Угу тебе уже кучу доводов привели. И про voliatil написали. Но у тебя какие то тараканы в голове и мешанина.


C>Не у меня.

C>Вот тебе конкретный пример:
C>
C>// Warning: Bad code
C>class LazyExample
C>{
C>  private BoxedInt _boxedInt; // Note: This field is not volatile
C>  int GetInt()
C>  {
C>    BoxedInt b = _boxedInt; // Read 1
C>    if (b == null)
C>    {
C>      b = new BoxedInt(42); // Write 1 (inside constructor)
C>      _boxedInt = b;        // Write 2 // Это разве конструктор!!!
C>    }
C>    return b._value;        // Read 2
C>  }
C>}
C>


C>Обрати внимание — поле в BoxedInt присваивается только в конструкторе.


Оно не readonly! int GetInt() не конструктор! GetInt объекта может вызываться из разных потоков!
и солнце б утром не вставало, когда бы не было меня
Re[46]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 08.03.22 17:15
Оценка: :)
Здравствуйте, Serginio1, Вы писали:

S> Оно не readonly! int GetInt() не конструктор!


Проблема — в new BoxedInt(42) и ссылке на объект. Напряги мозги.

S>GetInt объекта может вызываться из разных потоков!


Не может быть!
Ад пуст, все бесы здесь.
Re[47]: ConcurrentDictionary vs reference type
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.03.22 17:43
Оценка:
Здравствуйте, Codealot, Вы писали:

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


S>> Оно не readonly! int GetInt() не конструктор!


C>Проблема — в new BoxedInt(42) и ссылке на объект. Напряги мозги.


Нет проблема в
_boxedInt = b;


Ты устанавливаешь _boxedInt не в конструкторе.
BoxedInt b = _boxedInt; // Read 1
    if (b == null)
    {
      b = new BoxedInt(42); // Write 1 (inside constructor)
      _boxedInt = b;        // Write 2 // Это разве конструктор!!!
    }

S>>GetInt объекта может вызываться из разных потоков!

C>Не может быть!

Конечно! Ибо твой пример то не в кассу! Собери наконец мозги!
Ты все крутишься вокруг volatile причем в отличие от процессоhного memory barier https://habr.com/ru/post/130318/

Производительность Thread.Volatile* и ключевого слово volatile

На большинстве платформ (точнее говоря, на всех платформах, поддерживаемых Windows, кроме умирающей IA64) все записи и чтения являются volatile write и volatile read соответственно. Таким образом, во время выполнения ключевое слово volatile не оказывает никакого влияния на производительность. Напротив, методы Thread.Volatile*, во-первых, несут накладные расходы на сам вызов метода, помеченный как MethodImplOptions.NoInlining, и, во-вторых, в текущей реализации, создают полный барьер памяти. То есть, с точки зрения производительности, в большинстве случаев предпочтительнее использование ключевого слова.


Но на тебе лежит потокобезопасность объекта и производительность. И никакой ConcurrentDictionary тебе не поможет.
и солнце б утром не вставало, когда бы не было меня
Re[48]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 08.03.22 17:51
Оценка: :)
Здравствуйте, Serginio1, Вы писали:

S> Нет проблема в

S>
S>_boxedInt = b;
S>


Докажи.

S>На большинстве платформ (точнее говоря, на всех платформах, поддерживаемых Windows, кроме умирающей IA64) все записи и чтения являются volatile write и volatile read соответственно.


Какой забористый бред.
Ад пуст, все бесы здесь.
Re[3]: ConcurrentDictionary vs reference type
От: gusilebedi  
Дата: 08.03.22 23:20
Оценка: +1 -1 :)
Здравствуйте, Codealot, Вы писали:

C>Где написано, что она это гарантирует? Потому что я ничего подобного в ней не видел.


С превеликим удовольствием посылаю вас в man и RTFM, лучшего ответа вы не заслужили.
Re[45]: ConcurrentDictionary vs reference type
От: xpalex  
Дата: 09.03.22 09:48
Оценка:
Здравствуйте, Codealot, Вы писали:

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


C>Не у меня.

C>Вот тебе конкретный пример:
C>
C>// Warning: Bad code
C>class LazyExample
C>{
C>  private BoxedInt _boxedInt; // Note: This field is not volatile
C>  int GetInt()
C>  {
C>    BoxedInt b = _boxedInt; // Read 1
C>    if (b == null)
C>    {
C>      b = new BoxedInt(42); // Write 1 (inside constructor)
C>      _boxedInt = b;        // Write 2
C>    }
C>    return b._value;        // Read 2
C>  }
C>}
C>


C>Обрати внимание — поле в BoxedInt присваивается только в конструкторе.


ну и что с этим кодом не так?
Может ли быть создано больше одного BoxedInt? Да, может.
Может-ли GetInt() вернуть не 42? Нет, не может.

Вернемся к начальному вопросу из 1-го сообщения:
C> ConcurrentDictionary гарантирует безопасность объектов (если исходить из предположения, что они read-only)?

Какой опасности подвергаются или могут подвергаться readonly объекты хранящиеся в ConcurrentDictionary?
Re[46]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 09.03.22 15:22
Оценка:
Здравствуйте, xpalex, Вы писали:

X>ну и что с этим кодом не так?


Ты читай, а не упирайся рогом.

X>Может ли быть создано больше одного BoxedInt? Да, может.


Проблема не в этом.
Ад пуст, все бесы здесь.
Re[47]: ConcurrentDictionary vs reference type
От: xpalex  
Дата: 09.03.22 16:09
Оценка:
Здравствуйте, Codealot, Вы писали:

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


X>>ну и что с этим кодом не так?


C>Ты читай, а не упирайся рогом.


Т.е ты приводишь какой-то код и просишь найти где в нем что-то может пойти не так с точки зрения твоего незнания memory model CLR 2.0

C> b = new BoxedInt(42);


тут две записи. сначала будет записано 42 в выделенную область памяти (выделено под BoxedInt), потом адрес выделенного объекта будет записан в b.
mm clr 2.0 гарантирует. что эти операции не будут переупорядочены. (для x86, x64 это бесплатно, для ia64 и arm64 будут добавлены мемори барьеры.)

никакое переупорядочение чтений не сможет привести к попытке чтения поля объекта до чтения ссылки на объект. т.к. переупорядочиваться могут только операции с разными участками памяти.
или в твоем представлении возможно прочитать значение по адресу [p] до того как прочитан адрес p?

X>>Может ли быть создано больше одного BoxedInt? Да, может.


C>Проблема не в этом.


Так ты ж не говоришь в чем проблема. Привел код, но свое ожидание от этого кода не указал. Или мы по
C> // Warning: Bad code
должны понять что ты хочешь сделать не то, что написал?

Какую задачу своим кодом реашал и не решил?
Re[48]: ConcurrentDictionary vs reference type
От: Codealot Земля  
Дата: 09.03.22 16:55
Оценка:
Здравствуйте, xpalex, Вы писали:

X>Т.е ты приводишь какой-то код и просишь найти где в нем что-то может пойти не так с точки зрения твоего незнания memory model CLR 2.0


Это из той же ссылки, которую я давал тебе лично и которую ты очевидно не читал. https://docs.microsoft.com/en-us/archive/msdn-magazine/2013/january/csharp-the-csharp-memory-model-in-theory-and-practice-part-2
Кстати, с чего ты решил что свет сошелся клином именно на версии 2.0? Это единственная, которую ты знаешь?

X>или в твоем представлении возможно прочитать значение по адресу [p] до того как прочитан адрес p?


Один тред создает объект и передает ссылку на него в другой тред. Другой тред, который читает новый объект, прочитал ссылку раньше чем обновленные конструктором поля объекта. Не доходит?

X>Какую задачу своим кодом реашал и не решил?


Свои задачи я решаю всегда, в отличие от трепачей, которых я встречал в своей жизни куда больше, чем мне хотелось бы.
Ад пуст, все бесы здесь.
Re[49]: ConcurrentDictionary vs reference type
От: xpalex  
Дата: 10.03.22 01:55
Оценка: +1
Здравствуйте, Codealot, Вы писали:

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


X>>Т.е ты приводишь какой-то код и просишь найти где в нем что-то может пойти не так с точки зрения твоего незнания memory model CLR 2.0


C>Это из той же ссылки, которую я давал тебе лично и которую ты очевидно не читал. https://docs.microsoft.com/en-us/archive/msdn-magazine/2013/january/csharp-the-csharp-memory-model-in-theory-and-practice-part-2


Ты ниже кода, котрый ты скопипастил из статьи не прочитал что-ли?

A>However, this code will behave correctly (that is, always return 42) on all architectures in the .NET Framework versions 4 and 4.5:

A>
A>x86-x64:
A> Writes and reads will not be reordered. There is no store-load pattern in the code, and also no reason the compiler would cache values in registers.
A>Itanium:
A> Writes will not be reordered because they are ST.REL.
A> Reads will not be reordered due to data dependency.
A>ARM:
A> Writes will not be reordered because DMB is emitted before “_boxedInt = b.”
A> Reads will not be reordered due to data dependency.

Вообще пример про разъяснение реордеринга плохой — там в каждой строчке использование переменной b. А реордеринг разрешен только для инструкций с независимыми переменными.

C>Кстати, с чего ты решил что свет сошелся клином именно на версии 2.0? Это единственная, которую ты знаешь?

А в CLR 4 (2010 год) в отношении гарантий по памяти ничего не поменялось. CLR 3 не было, CLR 5+ еще не было. Или ты не знал?

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

Для с++,c да и любого языка, который наиболее близко компилируется в нейтив код, такая ситуация верна.
Для .net, который компилируется в CIL и только потом CLR-ом в нейтив — нет. Т.к. CLR добавляет барьеры для платформ там где требуется.

C>Свои задачи я решаю всегда, в отличие от трепачей, которых я встречал в своей жизни куда больше, чем мне хотелось бы.

Тогда уточни вопрос из первого сообщения темы: что за опасность подстерегает объекты, когда они хранятся в ConcurrentDictionary?
А прям идеально было бы кусок кода, который ведет себя некорректно при использовании ConcurrentDictionary.

Или
C>ConcurrentDictionary гарантирует безопасность объектов (если исходить из предположения, что они read-only), или нужны какие-то дополнительные движения с бубном?
это просто про потрепаться?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.