Конференция "Начинающим" » Как протестировать FLock:PRTLCriticalSection
 
  • Pavia © (12.03.18 05:58) [0]
    Есть 3 объекта.
    1 контроллер основного потока TFOrm1
    2 дополнительный поток TSylist
    3 общие данные TStringList.

    Сделать наследника TStraingList и в каждый метод напихать критическую секцию плохая идея, так как в таком случае будет непрерывный Lock. Что равносилен дедлоку.

    Поэтому  FLock:TRTLCriticalSection помещаю в TForm1

    Если поместить структуру FLock:TRTLCriticalSection в TSylist и после присвоить из TForm то критическая секция не работает - установлено опытным путём.

    Поэтому заменил на указатель. Теперь всё должно работать.

    Но у меня возник вопрос, а как вообще можно протестировать что критическая секция работает?
  • ага ага © (12.03.18 08:47) [1]
    где помещать разницы нету абсолютно.
    это вопрос дизайна кода.
    на рантайме секция уже не знает, где она была в коде. ей все равно.

    например тот же наследник TStringList.
    в его модуле переменная CS инициализаируется в секции initialisation
    перекрытые методы работы со списком работают через объект синхронизации.

    работает или нет можно не проверять, так как нет причин "не работать".
    но если очень хочется, то текстовый лог в внутри методов наследника с выводом времени входя/выхода и ид вызывающего потока.

    все проще некуда
  • Pavia © (12.03.18 09:40) [2]

    > где помещать разницы нету абсолютно.

    Я видимо плохо написал. Сейчас у меня CS в TForm1 и указатель на него в TStylist. Зачем нужен указатель? На этот вопрос я дал ответ так как если поместить CS в TChildStringList то это приведёт к тому что основной поток не сможет вклиниться так как второй постоянно будет захватывать его - хорошо известная проблема "не работы" мьютекса(вернее спинлока) и как следствие CS.

    Соответственно надо либо доказать, либо опровергнуть данное утверждение.


    > работает или нет можно не проверять, так как нет причин
    > "не работать".

    Вчера были причины "не работать". Проявлялись в том, что не те строки выводились пока не сделал лок глобальным.  Тем самым подтвердив что дело в нём.  В конечном счёте переписал на указатель.

    А позавчера общий объект не углядел, в самую верхнюю строку попадал мусор из других строк. Пришлось инстацировать. Хотя по идее CS должна была защитить.


    Но вопрос в том что данные ошибки были пойманы волей случая при ручном тестировании. И то не сразу, так как имели достаточно случайный характер. Такой же как с протекшими указателями и выходом индекса за пределы массива. А если бы был добавлен ещё кэш, то тогда бы ошибки ещё долго бы оставались незамеченными.


    > но если очень хочется, то текстовый лог в внутри методов
    > наследника с выводом времени входя/выхода и ид вызывающего
    > потока.

    Лог это всего лишь регистрация отклика объекта.  Тестирование это подача управляющего воздействия и получения результата. Вопрос в том как организовать, спланировать такое воздействие?
  • ага ага © (12.03.18 09:49) [3]
    Вчера были причины "не работать".

    единственная причина - неумение дизайнить код.

    крит секция как и любой другой объект, будучи создана живет в куче.
    и в каком модуле или классе или месте был вызван конструктор - по барабану.
    и где помещена переменная (или переменные) с указателем на этот объект - еще более по барабану.
  • Pavia © (12.03.18 12:15) [4]

    > единственная причина - неумение дизайнить код.

    Про дизайн я спрашивал в соседней ветки там все молчат.
    В данной ветки обсуждается тестирование.  


    > и в каком модуле или классе или месте был вызван конструктор
    > - по барабану.

    Критическая секция к вашему сведенью патчит секцию кода. Так что в них вы явно не разбираетесь. А посему мне с вами нет смысла вести беседу:
    - про дизайн вы уже показали свое незнание
    - в тестирование показали свое незнание
    - в устройстве CS тоже показали своё незнание.
  • ага ага © (12.03.18 12:57) [5]
    Критическая секция к вашему сведенью патчит секцию кода.

    походу с вами действительно только время терять.

    так как нифига она на самом деле не патчит.

    достаточно посмотреть ее исходный код.
  • ага ага © (12.03.18 13:00) [6]
    Лог это всего лишь регистрация отклика объекта.  Тестирование это подача управляющего воздействия и получения результата. Вопрос в том как организовать, спланировать такое воздействие?



    для чайника это конечно же только бла бла бла.

    а для понимающего это всё.

    если кс "работает" то в логе мы увидим, что с момента когда какой-то поток заакваирил секцию, никто в нее больше не входит до тех пор пока этот поток ее не покинет.

    время видим, currentthreadid видим.
    последовательность строк тоже видим.

    видим вообще все.
    чего еще надо?
  • ага ага © (12.03.18 13:03) [7]
    Если поместить структуру FLock:TRTLCriticalSection в TSylist и после присвоить из TForm то критическая секция не работает - установлено опытным путём.

    Поэтому заменил на указатель. Теперь всё должно работать.


    конечно должно.
    тем более что это с самого начала уже и было указателем без всяких замен.
  • Игорь Шевченко © (13.03.18 11:02) [8]

    > Критическая секция к вашему сведенью патчит секцию кода


    Как много нам открытий чудных. Пруф в студию
  • ларчик (13.03.18 11:15) [9]
    RTLCriticalSection не нужен
     // TFOrm1
    System.TMonitor.Enter(общие_данные_TStringList);
     общие_данные_TStringList.Add('data_from_контроллер_основного_потока_TFOrm1');
    System.TMonitor.Exit(общие_данные_TStringList);
    // TSylist
    System.TMonitor.Enter(общие_данные_TStringList);
     общие_данные_TStringList.Add('data_from_дополнительный_поток_TSylist');
    System.TMonitor.Exit(общие_данные_TStringList);




    > Если поместить структуру FLock:TRTLCriticalSection в TSylist
    > и после присвоить из TForm то критическая секция не работает
    > - установлено опытным путём.

    ясень-пень два разных рекорда = две разные крит секции )
 
Конференция "Начинающим" » Как протестировать FLock:PRTLCriticalSection
Есть новые Нет новых   [134427   +35][b:0][p:0.001]