serbod писал(а):olegy123 Все зависит от уровня безопасности и надежности программы. Для прототипов или экспериментов я тоже грешным делом не утруждаю себя соблюдением своих же правил - говорящие имена, удаление объектов, иерархичность взаимосвязей, try..finally, проверки параметров и отсутствие предупреждений компилятора при максимуме проверок. Собралась, запустилась, ну и норм. Но потом бывает страдаю от этого, когда беру куски кода из прототипа в рабочие проекты. У меня такие задачи, что программы работают в виде распределенной системы на тысячах машин, круглосуточно без выходных.
Вы там шо? Операционку переписываете или приделываете костыли?
В свое время, когда был очень молод, красив собой и много дури расцветало в голове.. занимался разной херней - вместо того чтобы в 1Ске v7.7 написать обработчик, делал анимированные барабаны.. хотел сделать многозадачность в 1Ске, типа когда идет обработка, бухи релаксировали над анимацией. Ходил хвастался к бухам, после чего дали мне пенделя.. почему то не оценили этот поступок..
В то же время я был очень увлечен безопасностью своего кода, стабильностью выполнения задачи.. и на простую функцию (z:=a/b;)мог написать десять проверок(считал что try except finally - придумали трусы).. деления на ноль, переполнения числа, а что делать с целой частью.. а что будет с дробной.. А что будет если проверка не сработает? И начинаю писать уже второй слой проверки.. проверку на проверку, которая проверять на нуль. Весело? В какой то момент я понял что это фобия и из него нужно бежать.
serbod писал(а):И мне приходится учитывать проблемы, с которыми большинство никогда не сталкивается - переполнение 32-битного таймера GetTickCount() в течении 40 дней, фрагментация сегментов динамической памяти, некритичные сбои железа - сетевых карт и модемов, дисков, USB-устройств. То, что обычно решают перезапуском программы или компьютера. В моем случае перезапуск - это крайняя мера. Даже регламентные работы по обновлению софта согласуются в министерстве, а если систему не удается восстаноить больше часа, то это уже ЧП и серьезное внутреннее расследование с поиском крайних. Поэтому я намеренно избегаю любого риска и неопределенности.
Чё то тут не понимаю, вы пишете операционку или подсчитываете тики? Может вы делаете драйвера для USB-устройств, сетевых карт и модемов? Может вы подпольно upgred для видокарт NVIDIA или AMD..
Слышал об одних хопцев которые сделали станок по восстановлению блинов на HDD, но когда они сделали подлые америкосы с хитрыми азиатами выпустили блины с большей плотностью и по цене меньше чем стоимость восстановления. Возможно все..
По поводу мнистерства - ответ такой они напридумывали ставить данную систему, хай несут ответственность.
Добавлено спустя 12 минут 48 секунд:serbod писал(а):Слышал, что аналогичные проблемы испытывали разработчики Майкрософт, которые сначала делали дешевую систему "одного рабочего дня" без гарантий, где любую проблему может решить перезапуском. Но когда винда массово стала ассоциироваться с глюками и продажи упали, им пришлось задуматься о надежности. Им пришлось выработать ограничения и правила, четко соблюдать их в ущерб производительности и удобству. Винда научилась привязывать выделяемые ресурсы (память, хендлы, дескрипторы GUI) к запросившему их приложению, а в некоторых случаях и потоку. А также проверять доступ к этим ресурсам, защищать от изменений другими приложениями. И при завершении потока или приложения освобождать эти ресурсы. В Win95 такого не было, любая программа могла потерять выделенные ресурсы, залезть в чужую область памяти или обратиться к открытому другими порту или устройству, и даже убить всю систему. В WinNT и далее с этим начали бороться и сейчас каждое приложение работает в своей виртуальной "песочнице", где многие устройства и функции эмулируются. В плане использования памяти, GUI и основных устройств ввода-вывода для программ все хорошо, винда дает программам возможность безболезненно совершать ошибки, лезть в освобожденную память и терять хендлы, за счет "бронирования" сегментов памяти за конкретной программой, даже если программа вернула память системе. При закрытии программы винда все подчистит и память станет неиспользуемой. Но если неиспользуемая память закончилась, то винда начинает повторно выделять память в "бронированных" участках, и если программа к ним повторно обратится, то получит сбой. С одной стороны, этот сбой может никогда и не случиться, если памяти хватает. А с другой стороны, если сбой случится, то будет очень трудно найти его причину. Насчет линукса не знаю, там вроде с этим построже и сбой будет при первом же некорректном использовании памяти.
видимо сами патчите винду раз такие глубокие познания..
По поводу "неиспользуемая память закончилась" - что такое может быть что так быстро память закончилась? Неужели вам 640кб ОЗУ вначале хватает? Что может размещаться в памяти?
У меня стоит вопрос по поводу обмена данными, использования stream между процессами. Там выгодно использовать memory map - но я понимаю что мне не нужно размещать 999Tb в 4Гб памяти, нужно стримить порциями.. фрагмент не будет привышать 128кб - то выделить в памяти 128кб вполне достаточно.. далее как в tutoral loop-ишь..
Linux использует принципы POSIX, винда типа тоже - у них 70% одинаковый подход.. поэтому перенос возможен и не так категорично сложен.
Добавлено спустя 15 минут 16 секунд:serbod писал(а):Насчет привязки ресурсов к потокам внутри приложения подробностей не помню. Вроде у мьютексов оно есть, и это может привести к бесконечным блокировкам при неправильном использовании. А TThread в винде как раз использует мьютекс в качестве семафора для WaitFor, и если вызвать WaitFor не из основного потока (и даже контекста в случае с DLL), то будет deadlock.
Нет, мьютекс это к ядру, есть таблица(как я понимаю) где ядро видит какие нити обратились(залочили) и соответственно не должны работать, пока кто то не освободит(unlock).
Работу мютексов(точнее семафоров) любят описывать на примере к доступу к файлу нескольких процессов.. действительно файловая система базируется на этих механизмов.
serbod писал(а):olegy123 писал(а):Если вы про запирание мьютексов - то во всех книжках этот случай расписан.
Значит, кто-то уже наступал на эти грабли, раз в книжках пишут. И вы тоже будет писать, если потратите месяцы и годы на поиск и устранение беды, которую можно было предотвратить за пять минут, не поленившись следовать простым правилам.
Когда вам нужно за пару дней написать рабочий стабильный код, тут брать череп(мьтютекс) бедного Йорика и рассуждать "быть или не быть, вот в чем вопрос" нет времени..
Подкачал шины у велосипеда, натянул цепь - и поехал..
Если бы было так сложно то мультипроцессорность преподавалось бы в очень специализированных учебниках, которые могли бы понять и пременять только люди с тремя ВО, имеющий опыт лет так за 10..
Но на самом деле - есть TThread и есть Exception - это все что нужно по минимуму для старта в этот мир.