А что получится, если два экземпляра логера будут писать в один лог-файл а не «куда-то еще»?
Ошибка получится.
Но лечить её синглтоном, это значит слишком сковывать свободу по переиспользованию класса логгера. Всё равно, что перхоть лечить гильотиной.
Да, в совершенном мире с розовыми пони можно просто отбросить то, что неудобно. Но вот какая беда-горе — мы то живем в реальном мире, и нужно обеспечить запись из многих потоков в один лог-файл. (а-ля EventLog или transaction log БД).
Понятно, что ошибка нам не нужна при записи в лог. И как-то будет решена такая проблема? Есть какие-то идеи и предложения по этому поводу? Возможно, типовые решения?
В основе приобретенного иммунитета лежит специфическая сенсибилизация Т-лимфоцитов, которые активизируют макрофаги в отношении микобактерий. Специфическое повышение активности макрофагов ведет к значительному усилению барьерной функции воспаления и к более полному уничтожению или подавлению микобактерий в местах внедрения.
Сочетание врожденного и приобретенного иммунитета предохранит подавляющее большинство детей от заболевания туберкулезом. Болезнь возникает лишь при ослаблении иммунитета. Приобретенный иммунитет обнаруживается на протяжении всего времени, пока сохраняются живые микобактерии в организме. При естественном заражении вирулентными бактериями Коха они персистируют практически пожизненно.
К сожалению, прививка этой вакциной не дает 100% гарантии, что человек не заболеет туберкулезом, но на сегодняшний день является единственным видом профилактики болезни, вкупе с хорошим питанием и здоровым образом жизни. Тем не менее, её эффективность высока для детей в возрасте до 5 лет, она в известной степени защищает их от милиарной формы туберкулеза и туберкулезного менингита, поэтому новорожденным такую прививку делают в первую очередь.
Что произойдет, если внутри «классов, которые в нём нуждаются» будет создан свой экземпляр логера
Ничего особенного, будет у класса свой экземпляр логгера, если ему надо писать ещё куда-то. Но, вообще, это плохой класс, если он сам создаёт себе логгеры. Сегодня он логгеры создаёт, а завтра будет на 0 делить? Непорядок…
А что получится, если два экземпляра логера будут писать в один лог-файл а не «куда-то еще»?
Как будет работать запись в один лог-файл, если у вас будет один логер, на несколько потоков?
Я офигеваю, как в этом можно увидеть «детишки себе глазик пластиковой вилочкой случайно не тыкнули»
M$ всегда декларировала безопастность как одна из целей .Net платформы.
Overview of the .NET Framework
…
In addition, the managed environment of the runtime eliminates many common software issues. For example, the runtime automatically handles object layout and manages references to objects, releasing them when they are no longer being used. This automatic memory management resolves the two most common application errors, memory leaks and invalid memory references.
В дополнение. обвесив кучей фич по декларативной и императивной безопастности. Это один из встроенных механизмов, не зависимо от того нравится это кому-то или нет.
Впрочем, .Net сейчас открыт — можете поправить M$, заодно обновить ECMA и ISO спецификации.
В чём проблема создать один логгер (идеально — в точке сборки) и передать его в классы, которые в нём нуждаются
Теперь поясните как static реализует запрет создания второго экземпляра?
Такая задача не стоит перед логгером. Вы выдумываете требования, которые не нужны для решения задачи.
Создается экземпляр логера
его инстанс п1 сохряется в каком-то внешнем static member, относительно «классов, которые в нём нуждаются»,
ссылка п2 в последствии инъектится/передается в «классы, которые в нём нуждаются»
Я все верно понял?
Инъектится через передачу интерфейса логера?
Что произойдет, если внутри «классов, которые в нём нуждаются» будет создан свой экземпляр логера и его попробуют присвоить вместо того, который заинъектили?
Я офигеваю с ваших представлений о static и threadstatic.
Мои то тут причем? Это цитаты из документация М$ по имплемнтации .Net и EСMA спецификация. С них и офигевайте :)
И как вы будете шарить между процессами (OS Process) singleton в таком случае?
singleton никак, потому что он кривой ))
static данные можно шарить средствами OS, замапливая одинаковые страницы памяти в разные процессы.
А кто за это отвечает? Кто создает разделямые страницы памяти и «мапит одинаковые страницы памяти в разные процессы»? Это ваш код или приложение работает с каким-то API?
В чём проблема создать один логгер (идеально — в точке сборки) и передать его в классы, которые в нём нуждаются
Никакой проблемы, может быть создан хоть в астрале.
В данном случае «классы, которые в нём нуждаются» — это границы системы, в рамках которой должен существовать один экзепляр логера? Правильно?
Есть такая штука, как static. И для неё singleton не требуется ;)
Есть static. Теперь поясните как static реализует запрет создания второго экземпляра?
A static field marked with ThreadStaticAttribute is not shared between threads. Each executing thread has a separate instance of the field, and independently sets and gets values for that field. If the field is accessed on a different thread, it will contain a different value.
An application domain is intended to isolate two applications running in the same OS process from one another by guaranteeing that they have no shared data.
Технически это означает что оно шарится по самому безопасному сценарию, а разработчик может сделать еще «безопаснее» (на вилку одеть пробку, что бы детишки себе глазик пластиковой вилочкой случайно не тыкнули)
Насчёт привязки к Application Domain — это аналогично разделению по процессам в c++. Там тоже нельзя (ну, только средствами языка:) сделать static, расшаренный между процессами.
Между процессами (OS Process ) или потоками (OS Threads )? И как вы будете шарить между процессами (OS Process) singleton в таком случае?
Да, но несколькими постами выше автор пренебрежительно упомянул, что есть ещё «семафоры всякие», из чего я понял, что он пробует построить синхронизацию без них, на чистой магии синглтона.
Будьте так любезны привести цитату или несколько, которые вынудили Вас к таким мыслям и поясните Вашу логическую цепочку, что привела к таким выводам.
Я постараюсь в дальнейшем учесть Ваши пояснения при выражении своих мыслей.
Т.е. сначала, один журнал файловой системы на всё приложение — это благо, а потом оказывается, что их можно создавать в каждом потоке. Что будет с бедной файловой системой, остаётся только догадываться.
qw1, простите, Вы читать умеете? Или у Вас случайно получилось приписать слова которые не говорил ваш оппонент/собеседник? Не могли бы Вы привести цитату, для подтверждения Ваших слов?
Лишь бы не признаваться, что синглтон для файловой системы или сокетов — так себе идея.
С интересом ознакомлюсь с примером работы с общим ресурсом, так что бы это имело логический смысл, предсказуемое проверяемое состояние после операций, а не «фарш» на выходе.
Можем для простоты рассмотреть файл в Windows, в рамках одного потока, нескольких потоков, в рамках нескольких процессов.
ВОЗ должен обосновать полезность прививок, поэтому вот прививки, и вот падение заболеваемости. Ну то есть уровень доказательства оставляет желать лучшего.
В вас есть шанс доказать что ВОЗ облажалась.
Мы берем двух детей, один с прививкой а другого нет.
Для привики, возмем из детдома. Хрен с ним, не жалко, все равно нафиг никому не нужен. Проколем ему весь цикл прививок (ведь привики это зло!)
И возьмем, гарантированно «чистого» ребенка. Думаю, вы вы согласились своего сына или дочь отдолжить для эксперимента?
Ну и начем их сажать на один горшок в детском саду, рядом кроватки поставят в одной группе, возить вы будет их в детский сад сами. В своей машине, Заодно будете подвозить в тубдиспансер больного с открытой формой туберкулеза (бомж или зэк, думаю, будут не против).
Да, и группа из детского сада и класс тоже будут из ваших соратников — не привитые. Для чистоты эксперимента. Они же тоже должны получить свою дозу успеха. Да и коллективный иммунитет это «миф и сказки».
Как думаете кто выживет к году 15 жизни? Ваш сын/дочь не привитые или подопытная крыска из детдома?
синглтон… по какому объективному критерию с DI не сравнивай
Так их и нельзя сравнивать. У них разные задачи.
Я уже показывал, что приводимые приемы заменить Singleton на DI + IoC по конечному результату дают тот же… SIngleton. Потому что задача «запрет более одного экземпляра класса в границах системы» никуда не делась.
вопрос «какие границы вашей «the system» это процесс? Поток? запрос? класс? и т.д.»
Вопрос как в этих границах у вас резализован «restricts»?
как только вы ответите себе на эти вопросы, все станет на свои места.
Имплементация — да.
Молоток стоматолога отличается от кувалды кузнеца как и от копра или отбойного молотка.
А цель — оказать ударную нагрузку/передать кинетическую энергию выполняет.
Если для вас молоток которым забивают гвозди и молоток для отбивания мяса это два принципиально разных молотка делающие разные вещи (по месту применения, а не по механике действия) тогда да.
Мне не интерсно обсуждать ручку молотков, мне интересно передача кинетичесой энергии в этой теме.
В случае с ARM и x86 очень малая часть документации распространяется открыто. На её основе не получится сделать эмулятор.
Так они сделали транслятор с ассемблера x86 на ассемблер ARM. документация то на ассемблер открыта. К Примеру «Intel x86 Software Develop Manuals», «Intel x86 Instruction Set Reference»
Вы смотрите конкретныю имплеметацию, на конкретном языке.
Например для .Net согласно ECMA «Common Language Infrastructure (CLI) Partition I Concepts and Architecture» private static field будет виден далеко не по процессу:
Static fields and static methods
Static fields are always restricted to a single application domain basis (see §12.5), but they can also be allocated on a per-thread basis.
А внутри, если посмотреть, будет механизм Thread Local Storage
Что, как мы понимаем сильно отличается от private static member для С++
C++ позволяет самому выбирать что, где и как хранить на низком уровне. .Net и Java такого не позволяют. Что бы детишки не поранились сильно, им дали пластиковый ножик :)
Дизайну без разницы на конкретную имплементацию, если решает задачу.
Да, в совершенном мире с розовыми пони можно просто отбросить то, что неудобно. Но вот какая беда-горе — мы то живем в реальном мире, и нужно обеспечить запись из многих потоков в один лог-файл. (а-ля EventLog или transaction log БД).
Понятно, что ошибка нам не нужна при записи в лог. И как-то будет решена такая проблема? Есть какие-то идеи и предложения по этому поводу? Возможно, типовые решения?
Сочетание врожденного и приобретенного иммунитета предохранит подавляющее большинство детей от заболевания туберкулезом. Болезнь возникает лишь при ослаблении иммунитета. Приобретенный иммунитет обнаруживается на протяжении всего времени, пока сохраняются живые микобактерии в организме. При естественном заражении вирулентными бактериями Коха они персистируют практически пожизненно.
К сожалению, прививка этой вакциной не дает 100% гарантии, что человек не заболеет туберкулезом, но на сегодняшний день является единственным видом профилактики болезни, вкупе с хорошим питанием и здоровым образом жизни. Тем не менее, её эффективность высока для детей в возрасте до 5 лет, она в известной степени защищает их от милиарной формы туберкулеза и туберкулезного менингита, поэтому новорожденным такую прививку делают в первую очередь.
А что получится, если два экземпляра логера будут писать в один лог-файл а не «куда-то еще»?
Как будет работать запись в один лог-файл, если у вас будет один логер, на несколько потоков?
M$ всегда декларировала безопастность как одна из целей .Net платформы.
В дополнение. обвесив кучей фич по декларативной и императивной безопастности. Это один из встроенных механизмов, не зависимо от того нравится это кому-то или нет.
Впрочем, .Net сейчас открыт — можете поправить M$, заодно обновить ECMA и ISO спецификации.
А конкретнее можете сказать какой компонент OS?
Я все верно понял?
Инъектится через передачу интерфейса логера?
Что произойдет, если внутри «классов, которые в нём нуждаются» будет создан свой экземпляр логера и его попробуют присвоить вместо того, который заинъектили?
Мои то тут причем? Это цитаты из документация М$ по имплемнтации .Net и EСMA спецификация. С них и офигевайте :)
А кто за это отвечает? Кто создает разделямые страницы памяти и «мапит одинаковые страницы памяти в разные процессы»? Это ваш код или приложение работает с каким-то API?
Никакой проблемы, может быть создан хоть в астрале.
В данном случае «классы, которые в нём нуждаются» — это границы системы, в рамках которой должен существовать один экзепляр логера? Правильно?
Есть static. Теперь поясните как static реализует запрет создания второго экземпляра?
Технически это означает что оно шарится по самому безопасному сценарию, а разработчик может сделать еще «безопаснее» (на вилку одеть пробку, что бы детишки себе глазик пластиковой вилочкой случайно не тыкнули)
Между процессами (OS Process ) или потоками (OS Threads )? И как вы будете шарить между процессами (OS Process) singleton в таком случае?
Какие по вашему свойства у синглтона?
По какием критериям вы определите что это Singleton?
Синхронизации чего?
Если я верно понял, у вас несколько экземпляров логеров, которые работают в нескольких потоках, и все они пишут в один файл?
Магия?
Будьте так любезны привести цитату или несколько, которые вынудили Вас к таким мыслям и поясните Вашу логическую цепочку, что привела к таким выводам.
Я постараюсь в дальнейшем учесть Ваши пояснения при выражении своих мыслей.
qw1, простите, Вы читать умеете? Или у Вас случайно получилось приписать слова которые не говорил ваш оппонент/собеседник? Не могли бы Вы привести цитату, для подтверждения Ваших слов?
С интересом ознакомлюсь с примером работы с общим ресурсом, так что бы это имело логический смысл, предсказуемое проверяемое состояние после операций, а не «фарш» на выходе.
Можем для простоты рассмотреть файл в Windows, в рамках одного потока, нескольких потоков, в рамках нескольких процессов.
В вас есть шанс доказать что ВОЗ облажалась.
Мы берем двух детей, один с прививкой а другого нет.
Для привики, возмем из детдома. Хрен с ним, не жалко, все равно нафиг никому не нужен. Проколем ему весь цикл прививок (ведь привики это зло!)
И возьмем, гарантированно «чистого» ребенка. Думаю, вы вы согласились своего сына или дочь отдолжить для эксперимента?
Ну и начем их сажать на один горшок в детском саду, рядом кроватки поставят в одной группе, возить вы будет их в детский сад сами. В своей машине, Заодно будете подвозить в тубдиспансер больного с открытой формой туберкулеза (бомж или зэк, думаю, будут не против).
Да, и группа из детского сада и класс тоже будут из ваших соратников — не привитые. Для чистоты эксперимента. Они же тоже должны получить свою дозу успеха. Да и коллективный иммунитет это «миф и сказки».
Как думаете кто выживет к году 15 жизни? Ваш сын/дочь не привитые или подопытная крыска из детдома?
Так их и нельзя сравнивать. У них разные задачи.
Я уже показывал, что приводимые приемы заменить Singleton на DI + IoC по конечному результату дают тот же… SIngleton. Потому что задача «запрет более одного экземпляра класса в границах системы» никуда не делась.
вопрос «какие границы вашей «the system» это процесс? Поток? запрос? класс? и т.д.»
Вопрос как в этих границах у вас резализован «restricts»?
как только вы ответите себе на эти вопросы, все станет на свои места.
Имплементация — да.
Молоток стоматолога отличается от кувалды кузнеца как и от копра или отбойного молотка.
А цель — оказать ударную нагрузку/передать кинетическую энергию выполняет.
Если для вас молоток которым забивают гвозди и молоток для отбивания мяса это два принципиально разных молотка делающие разные вещи (по месту применения, а не по механике действия) тогда да.
Мне не интерсно обсуждать ручку молотков, мне интересно передача кинетичесой энергии в этой теме.
Так они сделали транслятор с ассемблера x86 на ассемблер ARM. документация то на ассемблер открыта. К Примеру «Intel x86 Software Develop Manuals», «Intel x86 Instruction Set Reference»
Вы смотрите конкретныю имплеметацию, на конкретном языке.
Например для .Net согласно ECMA «Common Language Infrastructure (CLI) Partition I Concepts and Architecture» private static field будет виден далеко не по процессу:
А внутри, если посмотреть, будет механизм Thread Local Storage
Что, как мы понимаем сильно отличается от private static member для С++
C++ позволяет самому выбирать что, где и как хранить на низком уровне. .Net и Java такого не позволяют. Что бы детишки не поранились сильно, им дали пластиковый ножик :)
Дизайну без разницы на конкретную имплементацию, если решает задачу.