-
Есть 3 объекта.
1 контроллер основного потока TFOrm1
2 дополнительный поток TSylist
3 общие данные TStringList.
Сделать наследника TStraingList и в каждый метод напихать критическую секцию плохая идея, так как в таком случае будет непрерывный Lock. Что равносилен дедлоку.
Поэтому FLock:TRTLCriticalSection помещаю в TForm1
Если поместить структуру FLock:TRTLCriticalSection в TSylist и после присвоить из TForm то критическая секция не работает - установлено опытным путём.
Поэтому заменил на указатель. Теперь всё должно работать.
Но у меня возник вопрос, а как вообще можно протестировать что критическая секция работает?
-
где помещать разницы нету абсолютно.
это вопрос дизайна кода.
на рантайме секция уже не знает, где она была в коде. ей все равно.
например тот же наследник TStringList.
в его модуле переменная CS инициализаируется в секции initialisation
перекрытые методы работы со списком работают через объект синхронизации.
работает или нет можно не проверять, так как нет причин "не работать".
но если очень хочется, то текстовый лог в внутри методов наследника с выводом времени входя/выхода и ид вызывающего потока.
все проще некуда
-
> где помещать разницы нету абсолютно.
Я видимо плохо написал. Сейчас у меня CS в TForm1 и указатель на него в TStylist. Зачем нужен указатель? На этот вопрос я дал ответ так как если поместить CS в TChildStringList то это приведёт к тому что основной поток не сможет вклиниться так как второй постоянно будет захватывать его - хорошо известная проблема "не работы" мьютекса(вернее спинлока) и как следствие CS.
Соответственно надо либо доказать, либо опровергнуть данное утверждение.
> работает или нет можно не проверять, так как нет причин
> "не работать".
Вчера были причины "не работать". Проявлялись в том, что не те строки выводились пока не сделал лок глобальным. Тем самым подтвердив что дело в нём. В конечном счёте переписал на указатель.
А позавчера общий объект не углядел, в самую верхнюю строку попадал мусор из других строк. Пришлось инстацировать. Хотя по идее CS должна была защитить.
Но вопрос в том что данные ошибки были пойманы волей случая при ручном тестировании. И то не сразу, так как имели достаточно случайный характер. Такой же как с протекшими указателями и выходом индекса за пределы массива. А если бы был добавлен ещё кэш, то тогда бы ошибки ещё долго бы оставались незамеченными.
> но если очень хочется, то текстовый лог в внутри методов
> наследника с выводом времени входя/выхода и ид вызывающего
> потока.
Лог это всего лишь регистрация отклика объекта. Тестирование это подача управляющего воздействия и получения результата. Вопрос в том как организовать, спланировать такое воздействие?
-
Вчера были причины "не работать".
единственная причина - неумение дизайнить код.
крит секция как и любой другой объект, будучи создана живет в куче.
и в каком модуле или классе или месте был вызван конструктор - по барабану.
и где помещена переменная (или переменные) с указателем на этот объект - еще более по барабану.
-
> единственная причина - неумение дизайнить код.
Про дизайн я спрашивал в соседней ветки там все молчат.
В данной ветки обсуждается тестирование.
> и в каком модуле или классе или месте был вызван конструктор
> - по барабану.
Критическая секция к вашему сведенью патчит секцию кода. Так что в них вы явно не разбираетесь. А посему мне с вами нет смысла вести беседу:
- про дизайн вы уже показали свое незнание
- в тестирование показали свое незнание
- в устройстве CS тоже показали своё незнание.
-
Критическая секция к вашему сведенью патчит секцию кода.
походу с вами действительно только время терять.
так как нифига она на самом деле не патчит.
достаточно посмотреть ее исходный код.
-
Лог это всего лишь регистрация отклика объекта. Тестирование это подача управляющего воздействия и получения результата. Вопрос в том как организовать, спланировать такое воздействие?
для чайника это конечно же только бла бла бла.
а для понимающего это всё.
если кс "работает" то в логе мы увидим, что с момента когда какой-то поток заакваирил секцию, никто в нее больше не входит до тех пор пока этот поток ее не покинет.
время видим, currentthreadid видим.
последовательность строк тоже видим.
видим вообще все.
чего еще надо?
-
Если поместить структуру FLock:TRTLCriticalSection в TSylist и после присвоить из TForm то критическая секция не работает - установлено опытным путём.
Поэтому заменил на указатель. Теперь всё должно работать.
конечно должно.
тем более что это с самого начала уже и было указателем без всяких замен.
-
> Критическая секция к вашему сведенью патчит секцию кода
Как много нам открытий чудных. Пруф в студию
-
RTLCriticalSection не нужен
System.TMonitor.Enter(общие_данные_TStringList);
общие_данные_TStringList.Add('data_from_контроллер_основного_потока_TFOrm1');
System.TMonitor.Exit(общие_данные_TStringList);
System.TMonitor.Enter(общие_данные_TStringList);
общие_данные_TStringList.Add('data_from_дополнительный_поток_TSylist');
System.TMonitor.Exit(общие_данные_TStringList);
> Если поместить структуру FLock:TRTLCriticalSection в TSylist
> и после присвоить из TForm то критическая секция не работает
> - установлено опытным путём.
ясень-пень два разных рекорда = две разные крит секции )