Прога, написанная на Delphi 7/7.1, начинает ужасно глючить при включенном Hyperthreading. Я допускаю, что в проге есть баги, тем более, что я использую сторонние компоненты. Однако, если у кого-то есть информация, что это проблема именно дельфи или ОС, пожалуйста, поделитесь — rgst (at) mail (dot) ru. Спасибо.
Здравствуйте, <Аноним>, Вы писали:
А>Прога, написанная на Delphi 7/7.1, начинает ужасно глючить при включенном Hyperthreading. Я допускаю, что в проге есть баги, тем более, что я использую сторонние компоненты. Однако, если у кого-то есть информация, что это проблема именно дельфи или ОС, пожалуйста, поделитесь — rgst (at) mail (dot) ru. Спасибо.
Думаю, тебе стоит убрать сторонние компоненты.
У меня на работе нет Hyperthreading, а дома есть.
Глюков не наблюдал ни разу.
Используем либо стандартные компоненты, либо проверенные временем и с исходниками.
А сторонние компоненты и если тем более они без исходников —
Удачи...
... << RSDN@Home 1.1.4 beta 7 rev. 463>> А в Winamp'e: И ничего не слышно...
Дункан Маклауд любил ходить в лес и издеваться над кукушками.
138385660
Здравствуйте, <Аноним>, Вы писали:
А>Прога, написанная на Delphi 7/7.1, начинает ужасно глючить при включенном Hyperthreading. Я допускаю, что в проге есть баги, тем более, что я использую сторонние компоненты. Однако, если у кого-то есть информация, что это проблема именно дельфи или ОС, пожалуйста, поделитесь — rgst (at) mail (dot) ru. Спасибо.
Здравствуйте, <Аноним>, Вы писали:
А>Прога, написанная на Delphi 7/7.1, начинает ужасно глючить при включенном Hyperthreading. Я допускаю, что в проге есть баги, тем более, что я использую сторонние компоненты. Однако, если у кого-то есть информация, что это проблема именно дельфи или ОС, пожалуйста, поделитесь — rgst (at) mail (dot) ru. Спасибо.
Многопоточность прогой используется?
... << RSDN@Home 1.1.4 @@subversion >>
Re[2]: Hyperthreading
От:
Аноним
Дата:
07.07.05 12:05
Оценка:
Да.
Вот еще один момент. Сама IDE периодически вешается на машинах с HT.
Пока не пришла в голову мысль о влиянии HT на приложение, я очень долго сидел в дебаггере и чесал репу, видя как, например, на пустом месте возникает access violation, причем другие потоки явно не влияют на указатель, по которому этот эксепшен происходит.
Здравствуйте, <Аноним>, Вы писали:
А>Да.
А>Вот еще один момент. Сама IDE периодически вешается на машинах с HT.
А>Пока не пришла в голову мысль о влиянии HT на приложение, я очень долго сидел в дебаггере и чесал репу, видя как, например, на пустом месте возникает access violation, причем другие потоки явно не влияют на указатель, по которому этот эксепшен происходит.
Угу. Очень типичная проблема. Для начала проверь следующие грабли:
— флажок IsMutliThread должен быть установлен (если нет — устанавливай его руками)
— все указатели и переменные, для которых возможно кроспотоковое использование должны записываться не простым присваиванием, а с помощью функций типа InterlockedExchange — это гарантирует от проблемы рассинхронизации процессорных кэшей.
Здравствуйте, mkopachev, Вы писали:
M>Здравствуйте, <Аноним>, Вы писали:
А>>Пока не пришла в голову мысль о влиянии HT на приложение, я очень долго сидел в дебаггере и чесал репу, видя как, например, на пустом месте возникает access violation, причем другие потоки явно не влияют на указатель, по которому этот эксепшен происходит.
M> Угу. Очень типичная проблема. Для начала проверь следующие грабли: M> — флажок IsMutliThread должен быть установлен (если нет — устанавливай его руками) M> — все указатели и переменные, для которых возможно кроспотоковое использование должны записываться не простым присваиванием, а с помощью функций типа InterlockedExchange — это гарантирует от проблемы рассинхронизации процессорных кэшей.
Честно говоря, необходимость использования Interlocked-фукнций для всех присваиваний в этом контексте по крайней мере сомнительна.
Re[4]: Hyperthreading
От:
Аноним
Дата:
08.07.05 10:53
Оценка:
M> — флажок IsMutliThread должен быть установлен (если нет — устанавливай его руками)
Я использую только TThread, значит флаг должен 100% установиться сам.
M> — все указатели и переменные, для которых возможно кроспотоковое использование должны записываться не простым присваиванием, а с помощью функций типа InterlockedExchange — это гарантирует от проблемы рассинхронизации процессорных кэшей.
Здравствуйте, <Аноним>, Вы писали:
M>> — флажок IsMutliThread должен быть установлен (если нет — устанавливай его руками)
А>Я использую только TThread, значит флаг должен 100% установиться сам.
БД используешь? через что доступ если используешь?
Здравствуйте, <Аноним>, Вы писали:
M>> — флажок IsMutliThread должен быть установлен (если нет — устанавливай его руками)
А>Я использую только TThread, значит флаг должен 100% установиться сам.
M>> — все указатели и переменные, для которых возможно кроспотоковое использование должны записываться не простым присваиванием, а с помощью функций типа InterlockedExchange — это гарантирует от проблемы рассинхронизации процессорных кэшей.
А>Где почитать про рассинхронизацию?
Например в документации на Intel. Если память не изменят это третий том документации (системное программирование).
Здравствуйте, kuda2004, Вы писали:
K>Здравствуйте, mkopachev, Вы писали:
M>>Здравствуйте, <Аноним>, Вы писали:
А>>>Пока не пришла в голову мысль о влиянии HT на приложение, я очень долго сидел в дебаггере и чесал репу, видя как, например, на пустом месте возникает access violation, причем другие потоки явно не влияют на указатель, по которому этот эксепшен происходит.
M>> Угу. Очень типичная проблема. Для начала проверь следующие грабли: M>> — флажок IsMutliThread должен быть установлен (если нет — устанавливай его руками) M>> — все указатели и переменные, для которых возможно кроспотоковое использование должны записываться не простым присваиванием, а с помощью функций типа InterlockedExchange — это гарантирует от проблемы рассинхронизации процессорных кэшей.
K>Честно говоря, необходимость использования Interlocked-фукнций для всех присваиваний в этом контексте по крайней мере сомнительна.
Для ВСЕХ переменных и не предлагается. Только для тех, которые могут изменяться и считываться разными потоками. Например, локальные переменные функций однозначно не могут быть использованы разными потоками, так как находятся в разных стеках.
Если переменная может изменяться одним потоком, а считываться другим, то это необходимомо.
M> Для ВСЕХ переменных и не предлагается. Только для тех, которые могут изменяться и считываться разными потоками. Например, локальные переменные функций однозначно не могут быть использованы разными потоками, так как находятся в разных стеках. M> Если переменная может изменяться одним потоком, а считываться другим, то это необходимомо.
это называется конкурентный доступ и скорее всего реализованно. в делфях при работе с потоками основные проблеммы связанны с VCL и базами. там с многопоточностью напряг.
Здравствуйте, <Аноним>, Вы писали:
M>> Если переменная может изменяться одним потоком, а считываться другим, то это необходимомо.
А>32-битные чтения/записи гарантированно атомные, никаких синхронизаций не надо
это вы оптимизатору расскажете
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Best regards,
Oleg A. Bachin
Re[8]: Hyperthreading
От:
Аноним
Дата:
08.07.05 15:13
Оценка:
7/7.1, VCL используется как доктор прописал — в главном потоке
Здравствуйте, Аноним, Вы писали:
M>> Если переменная может изменяться одним потоком, а считываться другим, то это необходимомо.
А>32-битные чтения/записи гарантированно атомные, никаких синхронизаций не надо
Здравствуйте, mkopachev, Вы писали:
K>>Честно говоря, необходимость использования Interlocked-фукнций для всех присваиваний в этом контексте по крайней мере сомнительна.
M> Для ВСЕХ переменных и не предлагается. Только для тех, которые могут изменяться и считываться разными потоками. Например, локальные переменные функций однозначно не могут быть использованы разными потоками, так как находятся в разных стеках. M> Если переменная может изменяться одним потоком, а считываться другим, то это необходимомо.
Это я к тому сказал, что Interlocked-фукнции всего лишь один из механизмов — а ошибки в межпотоковой синхронизации бывают очень разные.
А>>>>Пока не пришла в голову мысль о влиянии HT на приложение, я очень долго сидел в дебаггере и чесал репу, видя как, например, на пустом месте возникает access violation, причем другие потоки явно не влияют на указатель, по которому этот эксепшен происходит.
M>>> Угу. Очень типичная проблема. Для начала проверь следующие грабли: M>>> — флажок IsMutliThread должен быть установлен (если нет — устанавливай его руками) M>>> — все указатели и переменные, для которых возможно кроспотоковое использование должны записываться не простым присваиванием, а с помощью функций типа InterlockedExchange — это гарантирует от проблемы рассинхронизации процессорных кэшей.
K>>Честно говоря, необходимость использования Interlocked-фукнций для всех присваиваний в этом контексте по крайней мере сомнительна.
M> Для ВСЕХ переменных и не предлагается. Только для тех, которые могут изменяться и считываться разными потоками. Например, локальные переменные функций однозначно не могут быть использованы разными потоками, так как находятся в разных стеках. M> Если переменная может изменяться одним потоком, а считываться другим, то это необходимомо.
И второе — рассчинхронизация процессорных кешей в случае использования HT мне представляется с трудом
Здравствуйте, Oleg A. Bachin, Вы писали:
OAB>Здравствуйте, mkopachev, Вы писали:
M>> Для ВСЕХ переменных и не предлагается. Только для тех, которые могут изменяться и считываться разными потоками. Например, локальные переменные функций однозначно не могут быть использованы разными потоками, так как находятся в разных стеках. M>> Если переменная может изменяться одним потоком, а считываться другим, то это необходимомо.
OAB>это называется конкурентный доступ и скорее всего реализованно. в делфях при работе с потоками основные проблеммы связанны с VCL и базами. там с многопоточностью напряг.
как раз-таки в базах — кадая транзакция в своем потоке и никаких проблем
наверное имеется в виду TDataSet который TDataSource — ам шлет сообщения синхронно ? или что ?
Здравствуйте, s.ts, Вы писали:
ST>Здравствуйте, Oleg A. Bachin, Вы писали:
OAB>>Здравствуйте, mkopachev, Вы писали:
M>>> Для ВСЕХ переменных и не предлагается. Только для тех, которые могут изменяться и считываться разными потоками. Например, локальные переменные функций однозначно не могут быть использованы разными потоками, так как находятся в разных стеках. M>>> Если переменная может изменяться одним потоком, а считываться другим, то это необходимомо.
OAB>>это называется конкурентный доступ и скорее всего реализованно. в делфях при работе с потоками основные проблеммы связанны с VCL и базами. там с многопоточностью напряг.
ST>как раз-таки в базах — кадая транзакция в своем потоке и никаких проблем ST>наверное имеется в виду TDataSet который TDataSource — ам шлет сообщения синхронно ? или что ?
сорьки что с запозданием — отпуск был...
имелся ввиду BDE. вопрос даже не стоя в Hyperthreading, просто на мультипроцессорных тачках имеются проблемы.
рекомендации борланда по решению проблем — "переходите на ADO", меня тогда больше ODBC устроил.
Здравствуйте, Oleg A. Bachin, Вы писали:
OAB>Здравствуйте, s.ts, Вы писали:
ST>>Здравствуйте, Oleg A. Bachin, Вы писали:
OAB>>>Здравствуйте, mkopachev, Вы писали:
M>>>> Для ВСЕХ переменных и не предлагается. Только для тех, которые могут изменяться и считываться разными потоками. Например, локальные переменные функций однозначно не могут быть использованы разными потоками, так как находятся в разных стеках. M>>>> Если переменная может изменяться одним потоком, а считываться другим, то это необходимомо.
OAB>>>это называется конкурентный доступ и скорее всего реализованно. в делфях при работе с потоками основные проблеммы связанны с VCL и базами. там с многопоточностью напряг.
ST>>как раз-таки в базах — кадая транзакция в своем потоке и никаких проблем ST>>наверное имеется в виду TDataSet который TDataSource — ам шлет сообщения синхронно ? или что ?
OAB>сорьки что с запозданием — отпуск был...
OAB>имелся ввиду BDE. вопрос даже не стоя в Hyperthreading, просто на мультипроцессорных тачках имеются проблемы. OAB>рекомендации борланда по решению проблем — "переходите на ADO", меня тогда больше ODBC устроил.
Хм, для локализации проблемы советую отключить один "процессор" для всего приложения.
SetProcessAffinityMask (GetCurrentProcess, 1)
Если заработает, то проблема именно с HyperThreading...
Дункан Маклауд любил ходить в лес и издеваться над кукушками.
