/home/shvydky/brain.log

Ученица продемонстировала хорошее знание предмета:

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

Всем читать, срочно!

При разработке потокобезопастного кода (как например BufferPool ), приходится часто задумываться о том что будет если несколько потоков сразу попробуют воспользоваться нашей функциональностью. Мы все грамотные люди, и знаем, что надо использовать объекты синхронизации. Какие? Гуру Сохацкий сразу скажет: критическая секция самый быстрый объект синхронизации, потому что,... а, неважно. И будет совершенно прав! Но! Взглянув внимательно на код BufferPool , мы видим что большинство операций со списком буферов, который мы и защищаем, только читают его. И только метод Allocate, в случае если он не нашел подходящий буфер и решил создать новый - изменяет список буферов. Это значит, что большинство пользователей нашего класса требуют блокировку только для чтения и абсолютно не мешают друг другу, и только очень редкие требуют блокировку для записи, которая мешает всем остальным. Какой выход? ReaderWriterLock . После того, как Вы сходили по приведенной ссылке и прочитали что это и как оно ра

Я не зря запостил сразу весь исходник класса BufferPool . В дальнейшем я собираюсь пройтись по тем маленьким решениям, которые неизбежно приходится принимать при проектировании и реализации классов и объяснить, почему я принял те решения, которые принял. Итак, паттерн IDisposable. Все знают что в .NET нет детерминированных деструкторов. Разработчики сделали все чтобы скрыть от нас тот момент, когда класс освобождается. Мы не можем вызвать деструктор сами. Взамен предлагают два подхода: IDisposable.Dispose() или Close() Функция Finalize() (имеет синтаксис деструктора в C#) Когда и какой надо использовать? IDisposable реализуем если выполняется одно или оба условия: Данный класс содержит неуправляемые (unmanaged) ресурсы. Данный класс содержит члены, которые реализуют IDisposable Finalize реализуем только в случае неуправляемых ресурсов. Внутренние классы освобождать вызовом Dispose() из Finalize() ненадо, даже запрещено(!), так как они уже могут быть о

Даже у самой простой задачи есть простое решение и правильное. К сожалению, это не всегда одно и то же.

Неожиданно много комментируемый пост "Пул потоков" заставил меня взглянуть пристальнее на некоторые модули, из недавно написанных, и кое-что подправить. Собственно, эти прогулки по исходникам стали причиной этого поста... Когда говорят о многопоточных прогаммах, действительно (склоняю голову в согласии с Максимом Сохацким, автором Open BeOS , который все время пытается напомнить об этом), чаще всего идет речь о операциях ввода-вывода которые выносятся в отдельный поток или вызываются асинхронно. А там где есть ввод и вывод, обязательно есть БУФЕР. То есть, кусок памяти, куда или откуда этот самый ввод/вывод происходит. "Ну и что?", - скажите Вы! А то, что выделение памяти, это тоже ресурсоемкая операция! Это в обычной "куче". В "куче", которой правляет сборщик мусора выделение дешевое (если верить Sun-у и Microsoft-у), но дорого обходится освобождение памяти. Так или иначе, работа с памятью - штука дорогая. Особенно, когда речь идет о выденении

Похоже что у Blogger-а что-то поломалось. При попытке добавить комментарий в чужой блог вылетает что такой блог не могут найти. Обидно :(

Microsoft -ам надоело работать и 15-го марта 2005-го года они целый день вместо работы будут писать в блоги умные мысли.

Microsoft раздает бесплатно книгу в PDF про то как правильно писать производительные решения, которые к тому же хорошо масштабируются: http://msdn.microsoft.com/perf Начал читать - достаточно много и обстоятельно. Однозначно надо всем читать!

На днях один хороший знакомый набросал прогу для того, чтобы проверить как работают два потока с одинаковым приоритетом на одно- и многопроцессорных машинах. Сделал он это на C++ (кстати, все помнят что потоки в C++ надо создавать с помощью _beginthread/_beginthreadex , а не с помощью CreateThread ). Другой, увидев это дело решил проверить какие особенности планирования потоков для управляемого кода. Ведь CLR-потоки не всегда однозначно соотносятся с потоками ОС. Оказалось что даже для CLR-потоков поведение достаточно ожидаемое (такое же как и для настоящих потоков). Но разговор не про это. Глянув в код этого товарища я обнаружил примерно следующее: class test { void Method1() { while ( true ) { Console.WriteLine( "x" ); } } void Method1() { while ( true ) { Console.WriteLine( "o" ); } } static void Main() { Thread t1 = new Thread( new ThreadStart(Method1)); Thread t2 = new Thread( new ThreadStart(Method2)); t

Очередной раз наткнулся на то, что не могу удалить сборку из GAC-а. Природа такого поведения понятна: при установке сборок в GAC можно вести список приложений, которым эта сборка нужна и тогда gacutil, при попытке удаления говорит: Unable to uninstall: assembly is required by one or more applications Pending references: SCHEME: ID: DESCRIPTION:< Windows Installer> После быстрого серфинга в инете нашел следующее решение : If you encounter this problem, it is very likely that you have run into an odd MSI registry corruption (at the time of this writing, the cause is unknown). Without getting into a long-winded explanation of how this registry corruption eventually results in the error message above, the common cause of this is a bogus default value set under one (or both) of the below registry keys: [HKCU\Software\Microsoft\Installer\Assemblies\Global] [HKLM\SOFTWARE\Classes\Installer\Assemblies\Global] If these keys are not empty (e.g. they contain a MSI descriptor

Думаю, если выпустить Кличков двух сразу, то може они его и замесят: Петербургский супертяжеловес Николай Валуев. Родился 21.08.1973 года. Рост 213 сантиметров, вес 150 килограмм. Дебют в профессионалах у Валуева состоялся 15 октября 1993 года. На ринге провел 39 боев, одержал 38 побед, 27 – нокаутом. Поражений не имеет. По рейтингу Всемирной боксерской ассоциации Николай входит в десятку сильнейших супертяжеловесов планеты. Шестикратный чемпион мира по версии ПАБА, трехкратный чемпион России.

Практически полный список блогов весьма уважаемых пацанов (и леди) за .NET. Стянул его с .Net Security Blog , но дописал немного своих. В формате OPML грузить отсюда: http://c2.ils.com.ua/~shvydky/ClrBloggers.opml Срочно всем читать!

Компания Axalto выпустила смарткарты с .NET Runtime-ом внутри (правда только ECMA-стандартная часть). .netcpu Corp выпустила процессорный модуль, который выполняет .NET программы. Oracle 10g Release 2 обещает поддержку CLR-ых хранимых процедур в следующем релизе (вслед за DB2) Вкуснотища!

Потратил еще часок-другой на настройки блога. Похоже, этому можно посвятить жизнь :)