Вверх ↑
Этот топик читают: Гость
Ответов: 9906
Рейтинг: 351
#31: 2009-07-22 22:48:37 ЛС | профиль | цитата
Dilma писал(а):
в обоих реализациях отсутствует вызов унаследованного деструктора - это надо исправить

Согласен. Я забыл, что в теории - TDebug.Destroy имеет право быть не пустым.

Dilma писал(а):
с точки зрения кода реализация получилась бы гораздо навороченнее по объему кода, но зато быстрее на одну команду процессора при вызове doSafeMode

Гораздо - это с десяток-другой байт кода, минус тот же код в "боевом" методе. Которые вызываются ОДИН раз
А "одна команда процессора", сбрасывающая конвейер, кстати говоря - вызывается ОЧЕНЬ МНОГО раз. Например, миллион

Экономия кода в отложенных конструкторах достигается за счет другого.
Например, в THIStrList._var_Array - отложенное конструирование. И если мы ничего к этой точке не подключали, то не требуется коды для CreateArray, Set, _Get, _Count, _Add.
Тут - в тему.

Dilma писал(а):
да, это лишнее

По умному, надо делать два абсолютно похожих элемента: с мьютексом, и с критической секцией.
Ну или "два в одном", по св-ву типа Global/Local
карма: 9

0
Разработчик
Ответов: 26304
Рейтинг: 2146
#32: 2009-07-22 22:54:07 ЛС | профиль | цитата
Galkov писал(а):
Ну или "два в одном", по св-ву типа Global/Local

Ну вот это -- интересное предложение, стоит подумать, а чего раньше не предложил, кинулся сразу ругаться
карма: 22

0
Ответов: 9906
Рейтинг: 351
#33: 2009-07-22 23:04:50 ЛС | профиль | цитата
Это предложение было не тебе.
Там было сказано "По умному", а не так, как это делаешь ты
карма: 9

0
Разработчик
Ответов: 26304
Рейтинг: 2146
#34: 2009-07-22 23:12:03 ЛС | профиль | цитата
Galkov писал(а):
Там было сказано "По умному"

Ну что ж, подождем, пока кто-то сделает "По умному". Мне, лично, абсолютно пофиг
------------ Дoбавленo в 08.29:
Galkov, вот ты меня глупым обозвал, значит мне можно задать глупый вопрос. Действительно, я воткнул, возможно, совершенно ненужный цикл. Но и твоя концепция с INFINITE не совсем понятна. Я исходил с позиции того, что повелся на твой INFINITE и подвесил очередь ожидания, а надо было, по моему глупому соображению, проверить доступность данных при Delay=0 и вывалиться обратно, освободив дальнейшее продвижение вертикальной цепи событий.
карма: 22

0
Ответов: 9906
Рейтинг: 351
#35: 2009-07-23 16:25:40 ЛС | профиль | цитата
Что занимательно, судя по суете на SVN -- я опять не ошибся
карма: 9

0
Разработчик
Ответов: 26304
Рейтинг: 2146
#36: 2009-07-23 16:50:59 ЛС | профиль | цитата
Galkov писал(а):
Что занимательно, судя по суете на SVN -- я опять не ошибся

Но мне тоже интересно, где я там накосячил
Можешь нормально сказать с чем ты не согласен, показать пути реализации, или будешь опять ерничать
карма: 22

0
Администрация
Ответов: 15295
Рейтинг: 1519
#37: 2009-07-23 17:30:42 ЛС | профиль | цитата
Galkov писал(а):
А "одна команда процессора", сбрасывающая конвейер, кстати говоря - вызывается ОЧЕНЬ МНОГО раз. Например, миллион

Galkov, в рамках классики я чего-то очень сильно сомневаюсь, что сей миллион хоть сколько-то скажется на производительсности приложения с учетом того, сколько еще миллионов таких же команд лежит между onEvent и doWork. Очевидно, что это не призыв писать абы как, но в контексте всего выше сказанного ваше замечание является мелкой придиркой, никак не соответствующей тому образу, от которого вы тут пытаетесь излагать свои мысли.

nesco, советую посмотреть реализации аналогичных задач в инете(вот тут например http://www.firststeps.ru/mfc/winapi/r.php?118 или еще лучше тут http://www.delphikingdom.com/asp/answer.asp?IDAnswer=63251), а не дожидаться советов от тех, кто заранее считает все сделанное не ими лично г..ом. Во всяком случае это более продуктивный подход.
карма: 27
0
Ответов: 9906
Рейтинг: 351
#38: 2009-07-24 01:00:40 ЛС | профиль | цитата
Dilma писал(а):
а не дожидаться советов от тех, кто заранее считает все сделанное не ими лично г..ом

Dilma, обрати внимание, это твои слова. Называется, оговорка по Фрэйду
А я же просто считаю, сделанное в последних ревизиях этого элемента - не выполняющим свое функциональное назначение. Не больше, но и не меньше
Объективная характеристика, не имеющая никакого отношения к автору действа. Если бы это сделал ты, tsdima, Кладов - сказал бы то же самое. Правда, если бы я - ничего не говорил бы, а сделал бы все для исправления.
Вот ты мне указал на ошибку с inherited - так спасибо тебе большое за это
В своем коде я это исправил.

Научитесь также относиться к указанию на ошибку - станете профессионалами.
А пока-что в дистрибутив включается код больше по признаку авторства, чем корректности. Еще раз - не мною производится такая селекция, а Вами
Так-что, попробуйте лучше применить свою фразу к себе

карма: 9

0
Разработчик
Ответов: 26304
Рейтинг: 2146
#39: 2009-07-24 01:18:50 ЛС | профиль | цитата
Galkov писал(а):
А я же просто считаю, сделанное в последних ревизиях этого элемента - не выполняющим свое функциональное назначение

Пустой треп, напоминающий троллизм, ни больше и не меньше. Где доказательства не выполнения функционального назначения

Вопрос был задан конкретно -- где в концепции ошибки, и чем твой пример лучше того, что сделано Докажи, что твоя концепция лучше, или что, тебе надо верить на слово, тк есть такой Galkov, и он всегда прав, а все тут мимо проходили

Galkov писал(а):
Научитесь также относиться к указанию на ошибку - станете профессионалами

И где эти указания, и кто сказал, что они ошибочны, а, Galkov сказал, ну тогда -- да...
карма: 22

0
Ответов: 9906
Рейтинг: 351
#40: 2009-07-24 01:49:51 ЛС | профиль | цитата
nesco, от того, что ты назовешь меня тролем, ОНО РАБОТАТЬ НЕ НАЧНЕТ
А меня обидеть невозможно, я и не такое слышал

Пересказывать тебе то, что написано в букварях - значительно сложнее, чем сделать самому. Что я и сделал.
Не первый раз, между прочим.
Но намекну
Критические секции в твоем исполнении не могут выполнить задачу зашиты ресурса, даже теоретически, УЖЕ ТОЛЬКО ПОТОМУ - что не используется св-во Name.
Просто отсутствует критерий защиты. Напрочь отсутствует. Нет его.
После этого коды можно и не смотреть (хотя там тоже смешно)
карма: 9

0
Разработчик
Ответов: 26304
Рейтинг: 2146
#41: 2009-07-24 02:23:22 ЛС | профиль | цитата
Galkov писал(а):
Критические секции в твоем исполнении не могут выполнить задачу зашиты ресурса, даже теоретически, УЖЕ ТОЛЬКО ПОТОМУ - что не используется св-во Name

Ссылку на букварь, где написано, что структура TRTLCriticalSection должна нести в себе имя Name

Не постесняюсь привести Рихтера. Ткни пальцем, где там написано, что секция должна иметь уникальное имя.

Рихтер писал(а):
Теперь, когда у Вас появилось общее представление о критических секциях (зачем они нужны и как с их помощью можно монопольно распоряжаться разделяемым ресурсом), давайте повнимательнее приглядимся к тому, как они устроены. Начнем со структуры CRITICAL_SECTION. Вы не найдете ее в Platform SDK — о ней нет даже упоминания. В чем дело?

Хотя CRITICAL_SECTION не относится к недокументированным структурам, Microsoft полагает, что Вам незачем знать, как она устроена. И это правильно. Для нас она является своего рода черным ящиком - сама структура известна, а ее элементы — нет. Конечно, поскольку CRITICAL_SECTION — не более чем одна из структур, мы можем сказать, из чего она состоит, изучив заголовочные файлы. (CRITICATL_SECTlON определена в файле WinNT.h как RTL_CRITICAL_SECTION, а тип структуры RTL_CRITICAL_SECTION определен в файле WinBase.h,) Но никогда не пишите код, прямо ссылающийся на ее элементы.

Вы работаете со структурой CRITICAL_SECTION исключительно через функции Windows, передавая им адрес соответствующего экземпляра этой структуры Функции сами знают, как обращаться с ее элементами, и гарантируют, что она всегда будет в согласованном состоянии. Так что теперь мы перейдем к рассмотрению этих функций.

Обычно структуры CRITICAL_SECTION создаются как глобальные переменные, доступные всем потокам процесса. Но ничто не мешает нам создавать их как локальные переменные или переменные, динамически размещаемые в куче. Есть только два условия, которые надо соблюдать. Во-первых, все потоки, которым может понадобиться ресурс, должны знать адрес структуры CRITICAL_SECTION, которая защищает этот ресурс. Вы можете получить ее адрес, используя любой из существующих механизмов. Во-вторых, элементы структуры CRITICAL_SECTION следует инициализировать до обращения какого-либо потока к защищенному ресурсу. Структура инициализируется ВЫЗОВОМ:

VOID InitializeCriticalSection(PCRITICAL_SECTION pcs);

Эта функция инициализирует элементы структуры CRITICAL_SECTION, на которую указывает параметр pcs. Поскольку вся работа данной функции заключается в инициализации нескольких переменных-членов, она не дает сбоев и поэтому ничего не возвращает (void). InitializeCriticalSection должна быть вызвана до того, как один из потоков обратится к EnterCriticalSection. В документации Platform SDK недвусмысленно сказано, что попытка воспользоваться неинициализированной критической секцией даст непредсказуемые результаты


Ясно и конкретно написано, что трогать структуру нельзя, этим занимается специальная функция.

Если речь не об этом, тогда просьба уточнить, что имелось в виду под словом Name

Galkov писал(а):
хотя там тоже смешно

В чем конкретно наблюдается "смешная реализация"

------------ Дoбавленo в 02.31:
Может возникнуть тычек пальцем в спин блокировку, но тут читаем опять Рихтера

Рихтер писал(а):
На мой взгляд, используя критические секции, Вы должны всегда применять спин-блокировку — терять Вам просто нечего. Moгут возникнуть трудности в подборе значения dwSpinCount, но здесь нужно просто поэкспериментировать


карма: 22

0
Ответов: 9906
Рейтинг: 351
#42: 2009-07-24 02:39:03 ЛС | профиль | цитата
Шарик, ты - БАЛБЕС

Назови мне хоть одну причину, по которой в твоем коде TryEnterCriticalSection вернет FALSE
Ее нет, никогда не вернет. Нахрена оно там тогда вообще стоит - это только тебе известно.
Ты можешь из трусов выпрыгивать, знакомые буквы в учебниках выискивать, про "великого Galkov-а" вспоминать - все равно, НИКОГДА НЕ ВЕРНЕТ

ЗАЩИТА - это прежде всего ожидание, пока ресурс не освободится. В том и защита, что не лезу как дурак к ресурсу, а сначала жду.
У тебя нет ф-ии ожидания для критической секции - это ОЧЕНЬ СМЕШНО, когда некто утверждает, что занимается защитой ресурса без ф-ий ожидания.
Ожидание, это EnterCriticalSection, а в твоем исполнении она НИКОГДА ЖДАТЬ НЕ БУДЕТ. Потому-что эту кр.секцию никто не занимал.
Поймешь эту сверх-очевидную вещь - вспомни про Name.


карма: 9

0
Разработчик
Ответов: 26304
Рейтинг: 2146
#43: 2009-07-24 02:47:07 ЛС | профиль | цитата
Galkov писал(а):
Нахрена оно там тогда вообще стоит - это только тебе известно

Это почему же

Рихтер писал(а):
Вместо EnterCriticalSection Вы можете воспользоваться;

BOOL TryEnterCriticalSection(PCRITICAL_SECTION pcs);

Эта функция никогда не приостанавливает выполнение вызывающего потока. Но возвращаемое ею значение сообщает, получил ли этот поток доступ к ресурсу. Если при ее вызове указанный ресурс занят другим потоком, она возвращает FALSE

Galkov писал(а):
Ее нет, никогда не вернет

Запусти пример, который я сделал по твоим зарисовкам, расставь debug-и и посмотри, ворачивается ли там False и сколько раз Фиг там запустишь второй раз цикл, пока в первом потоке он не отработает
------------ Дoбавленo в 03.03:
И еще вопрос, который уже задавался -- зачем переводить поток в режим ожидания, когда просто можно проверить доступность ресурса, а если он занят, то продолжить дальнейшую очередь событий не останавливая поток. Тут было два пути решения, либо виснем на ожидании доступности, либо продолжаем выполнять дальше свои действия по циклу и ждать, пока не освободится
------------ Дoбавленo в 03.11:
ПМСМ. Необходимо, чтобы кто-то еще просмтрел код и пример и сказал, выполнет ли данный компонент функцию защиты или нет. В данной реализации используются метод не торможения потоков и перевод их в режим ожидания, а необходимость циклического опроса состояния доступности. Это две разные концепции, и я не вижу ни за, ни против, ни против той, ни против другой, они обе имеют право на существование
карма: 22

0
Ответов: 9906
Рейтинг: 351
#44: 2009-07-24 03:14:27 ЛС | профиль | цитата
Хорошо согласен, бывает случай когда false возвращается.
Это невероятный случай (упущенный мной), когда доступ к ресурсу, это одно и то же действие. Кольцевание эдакое такое - вход в метод еще до выхода предыдущего входа.

Но задача в том, что это должны быть и разные действия. Разные элементы с одним именем должны защищать в том числе и разные исполнительные ветки.
Одна, например прибавляет чего-то к элементам огромного массива, вторая - отнимает. Или одна пишет в файл, вторая - читает из него
Это задача такая, это не я ее придумал, она во всем мире такая, она только у тебя другая почему-то.
Для мьтексов, к примеру - это так. Тоже самое выполнимо и для критических секций.


карма: 9

0
Разработчик
Ответов: 26304
Рейтинг: 2146
#45: 2009-07-24 03:29:46 ЛС | профиль | цитата
Galkov писал(а):
Но задача в том, что это должны быть и разные действия. Разные элементы с одним именем должны защищать в том числе и разные исполнительные ветки

Да, с эти я согласен. Но как приписать имя критической секции, если она его не поддерживает, в отличии от мьютекса

И еще один вопрос остался открытым -- тормозить ли второй поток, ведь в этом случае, он повиснет и ничего дальше делать не будет, пока не освободится ресурс. Это можно было реализовать добавлением некоего свойства переключающего такой режим ждать/не ждать
карма: 22

0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)