Здравствуйте, nikov, Вы писали:
N>Порядок, в котором другой поток, выполняющийся на другом проце с другими кэшами, увидит эти изменения может быть другим. Смысл — ускорить работу за счет снижения гарантий. Тот, кому нужны гарантии — вставляет ручную синхронизацию и барьеры (например, их могут вставлять компиляторы из языков высокго уровня в IL) и профилирует замедление.
Не может он быть другим. Или другой поток увидит null и войдет в if или не увидит и получит ссылку на сформированный объект.
Кончайте выдумывать. И вообще, проблемы дефолтного компаратора — это проблемы МС, так как они его писали. Можете создать описание бага и посмотреть что вам ответят.
К данной же теме это не имеет никакого отношения.
ЗЫ
Что за привычка любой разговор в диспут превращать? Так ничего в жизни не сделаешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>1. Итак, ничего страшного получить мы не должны КЛ>2. Если под конструктором тут понимается конструктор объекта, тот тут опять нет ничего такого, что подтверждает вашу теорию.
Елы-палы. Фраза "CLI совершенно не обязана гарантировать, что все изменение состояния, происходящие в конструкторе, должны быть одинаково видны пока конструктор не отработает" не отвергает того факта, что по окончанию работы конструктора состояние объекта должно быть одинаково видно всем кому дали ссылку на него.
КЛ>В общем, ничего существенного этот абзац нам не дает.
Вот именно. В том смысле, что она тут просто не к месту. Оно о другом.
Есть четкий порядок создания объекта:
1. Выделение памяти.
2. Работа конструктора.
3. Присвоение ссылки переменной.
Дотнет гарантирует, что ссылка присваивается только на сформированный объект.
Что до кэшей процессоров, то если они будут разными, то потребуется сбрасывать их при обращении к любому разеляемому объекту. Это сделает неверным половину кода в библиотеках донтета.
Ну, а переписывание таких объемов кода уже и правда паранойя.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>Читай дальше: он получит эту ссылку позже, но до того, как получит возможность прочитать кусок памяти, в котором находится объект.
А что он читать то будет? Откуда у него кэш взялся? Он же к этой области памяти еще не обращался. Если же у него есть кэш, то он и нули может не увидеть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Дотнет гарантирует, что ссылка присваивается только на сформированный объект.
Но не гарантирует что второй поток увидит сформированный объект раньше чем ссылку на него.
VD>Что до кэшей процессоров, то если они будут разными, то потребуется сбрасывать их при обращении к любому разеляемому объекту. Это сделает неверным половину кода в библиотеках донтета.
Половину говоришь?
Ну тогда тебе не составит труда показать где еще в .NET'те есть race condition'ы.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, nikov, Вы писали:
КЛ>>Кароче, это что-то из ряда фантастики. Как тогда проги писать, простите? N>Далеко не все проги многопоточные. А многопоточные используют синхронизацию или вообще высокоуровневые феймворки, в которых уже все продумано и протестировано.
Исходя из ваших рассуждений все коллекции использующие компараторы или им подобные объекты (т.е. просто все коллекции фрэймворка) не являются потокобезопасными в принципе.
Если это так, то как дотнет можно использовать для создания многопоточных приложений?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>С такой что, это, как минимум, логично и не просаживает перфоманс. Как ты думаешь, что бы было, если бы значение ссылки и то, на что она указывает хотя бы в половине случаев не лежало в одном кеше или в одной линейке кеша?
Не думаю, что производительность как-то изменилась бы если после вызова конструктора и перед присвоением ссылки полю был бы вызов Thread.MemoryBarrier().
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Исходя из ваших рассуждений все коллекции использующие компараторы или им подобные объекты (т.е. просто все коллекции фрэймворка) не являются потокобезопасными в принципе.
Так и есть.
Починить это можно расстановкой барьеров памяти или lock'а.
VD>Если это так, то как дотнет можно использовать для создания многопоточных приложений?
Похоже что нельзя.
Правда окно в котором эта проблема может проявиться очень маленькое.
Также возможно что некоторые особенности текущей реализации не дают этой проблеме проявится.
Но стандарт не гарантирует что этого не случится в некоторых других реализациях.
Например под другой процессор.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
КЛ>>С такой что, это, как минимум, логично и не просаживает перфоманс. Как ты думаешь, что бы было, если бы значение ссылки и то, на что она указывает хотя бы в половине случаев не лежало в одном кеше или в одной линейке кеша?
VD>Не думаю, что производительность как-то изменилась бы если после вызова конструктора и перед присвоением ссылки полю был бы вызов Thread.MemoryBarrier().
Я не про это. Я про ситуацию, когда ссылка и память не лежат рядом в кеше.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VladD2, Вы писали:
VD>>Исходя из ваших рассуждений все коллекции использующие компараторы или им подобные объекты (т.е. просто все коллекции фрэймворка) не являются потокобезопасными в принципе. WH>Так и есть. WH>Починить это можно расстановкой барьеров памяти или lock'а.
VD>>Если это так, то как дотнет можно использовать для создания многопоточных приложений? WH>Похоже что нельзя. WH>Правда окно в котором эта проблема может проявиться очень маленькое. WH>Также возможно что некоторые особенности текущей реализации не дают этой проблеме проявится. WH>Но стандарт не гарантирует что этого не случится в некоторых других реализациях. WH>Например под другой процессор.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VladD2, Вы писали:
VD>>Дотнет гарантирует, что ссылка присваивается только на сформированный объект. WH>Но не гарантирует что второй поток увидит сформированный объект раньше чем ссылку на него.
А откуда возмещается кэш то на эту область памяти?
VD>>Что до кэшей процессоров, то если они будут разными, то потребуется сбрасывать их при обращении к любому разеляемому объекту. Это сделает неверным половину кода в библиотеках донтета. WH>Половину говоришь? WH>Ну тогда тебе не составит труда показать где еще в .NET'те есть race condition'ы.
А зачем еще? Этот компаратор используется в половине коллекций. В другой половине коллекций используется System.Collections.Generic.EqualityComparer<T> в котором поле faultComparer инициализируется точно так же.
Можно конечно рассуждать как Ников. Типа конкретная реализация — донет гарантирует работоспособность этого кода, а в Моно сам EqualityComparer<T> может быть написан по другому. Но при этом опять же мы наблюдаем битву с ветряными мельницами.
В противном же случае гонки будут в любом коде использующем стандартные коллекции.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Также возможно что некоторые особенности текущей реализации не дают этой проблеме проявится.
Ну, а что ты тогда в исходники Comparer и EqualityComparer смотришь? Пусть те кто делает другой рантайм и заботятся о реализации этих классов.
WH>Но стандарт не гарантирует что этого не случится в некоторых других реализациях. WH>Например под другой процессор.
Стандарт гарантирует, что я могу пользоваться коллекциями основанными на компараторе в разных потоках.
Так что или мы говорим о очень тонком и хорошо завуалированном баге дотнета, или вы действительно перебарщиваете с паранойей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
VD>>Не думаю, что производительность как-то изменилась бы если после вызова конструктора и перед присвоением ссылки полю был бы вызов Thread.MemoryBarrier().
КЛ>Я не про это. Я про ситуацию, когда ссылка и память не лежат рядом в кеше.
А почему они должны лежать рядом? Это никто гарантировать не может.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
VD>>>Не думаю, что производительность как-то изменилась бы если после вызова конструктора и перед присвоением ссылки полю был бы вызов Thread.MemoryBarrier().
КЛ>>Я не про это. Я про ситуацию, когда ссылка и память не лежат рядом в кеше.
VD>А почему они должны лежать рядом? Это никто гарантировать не может.
Я не про то что должны, а про то что это было бы логично и эффективно
Здравствуйте, VladD2, Вы писали:
VD>Но это чушь, так как вот этот самый сервер держит по 200 параллельных клиентов и ни разу (вороде) не упал от null-ref-исключения по этому поводу.
Из-за этого можно упасть только на взлете.
После того как сервер прогрелся из-за этого уже не упасть.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VladD2, Вы писали:
VD>>Но это чушь, так как вот этот самый сервер держит по 200 параллельных клиентов и ни разу (вороде) не упал от null-ref-исключения по этому поводу. WH>Из-за этого можно упасть только на взлете. WH>После того как сервер прогрелся из-за этого уже не упасть.
Всё новые и новые знания ты нам открываешь. Источник бы...
Здравствуйте, VladD2, Вы писали:
WH>>Также возможно что некоторые особенности текущей реализации не дают этой проблеме проявится. VD>Ну, а что ты тогда в исходники Comparer и EqualityComparer смотришь? Пусть те кто делает другой рантайм и заботятся о реализации этих классов.
Так если реализацию рантайма изменят то может и всплыть.
VD>Так что или мы говорим о очень тонком и хорошо завуалированном баге дотнета, или вы действительно перебарщиваете с паранойей.
Если подходить с точки зрения стандарта то первое.
Если текущая реализация дает более сильные гарантии чем стребует стандарт то второе. Но это весьма зыбко ибо гарантии могут и ослабить до реальных требований стандарта.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
[]
VD>>Так что или мы говорим о очень тонком и хорошо завуалированном баге дотнета, или вы действительно перебарщиваете с паранойей. WH>Если подходить с точки зрения стандарта то первое. WH>Если текущая реализация дает более сильные гарантии чем стребует стандарт то второе. Но это весьма зыбко ибо гарантии могут и ослабить до реальных требований стандарта.
