M> Если переменная может изменяться одним потоком, а считываться другим, то это необходимомо.

32-битные чтения/записи гарантированно атомные, никаких синхронизаций не надо

Прога, написанная на Delphi 7/7.1, начинает ужасно глючить при включенном Hyperthreading. Я допускаю, что в проге есть баги, тем более, что я использую сторонние компоненты. Однако, если у кого-то есть информация, что это проблема именно дельфи или ОС, пожалуйста, поделитесь — rgst (at) mail (dot) ru. Спасибо.

Здравствуйте, <Аноним>, Вы писали:

А>Прога, написанная на Delphi 7/7.1, начинает ужасно глючить при включенном Hyperthreading. Я допускаю, что в проге есть баги, тем более, что я использую сторонние компоненты. Однако, если у кого-то есть информация, что это проблема именно дельфи или ОС, пожалуйста, поделитесь — rgst (at) mail (dot) ru. Спасибо.

Думаю, тебе стоит убрать сторонние компоненты.
У меня на работе нет Hyperthreading, а дома есть.
Глюков не наблюдал ни разу.
Используем либо стандартные компоненты, либо проверенные временем и с исходниками.

А сторонние компоненты и если тем более они без исходников —

Удачи...

Здравствуйте, <Аноним>, Вы писали:

А>Прога, написанная на Delphi 7/7.1, начинает ужасно глючить при включенном Hyperthreading. Я допускаю, что в проге есть баги, тем более, что я использую сторонние компоненты. Однако, если у кого-то есть информация, что это проблема именно дельфи или ОС, пожалуйста, поделитесь — rgst (at) mail (dot) ru. Спасибо.

телепаты все еще в отпуске.

Здравствуйте, <Аноним>, Вы писали:

А>Прога, написанная на Delphi 7/7.1, начинает ужасно глючить при включенном Hyperthreading. Я допускаю, что в проге есть баги, тем более, что я использую сторонние компоненты. Однако, если у кого-то есть информация, что это проблема именно дельфи или ОС, пожалуйста, поделитесь — rgst (at) mail (dot) ru. Спасибо.

Многопоточность прогой используется?

Да.

Вот еще один момент. Сама IDE периодически вешается на машинах с HT.

Пока не пришла в голову мысль о влиянии HT на приложение, я очень долго сидел в дебаггере и чесал репу, видя как, например, на пустом месте возникает access violation, причем другие потоки явно не влияют на указатель, по которому этот эксепшен происходит.

Здравствуйте, <Аноним>, Вы писали:

А>Да.

А>Вот еще один момент. Сама IDE периодически вешается на машинах с HT.

А>Пока не пришла в голову мысль о влиянии HT на приложение, я очень долго сидел в дебаггере и чесал репу, видя как, например, на пустом месте возникает access violation, причем другие потоки явно не влияют на указатель, по которому этот эксепшен происходит.

Угу. Очень типичная проблема. Для начала проверь следующие грабли:
— флажок IsMutliThread должен быть установлен (если нет — устанавливай его руками)
— все указатели и переменные, для которых возможно кроспотоковое использование должны записываться не простым присваиванием, а с помощью функций типа InterlockedExchange — это гарантирует от проблемы рассинхронизации процессорных кэшей.

С уважением Михаил Копачев

Здравствуйте, mkopachev, Вы писали:

M>Здравствуйте, <Аноним>, Вы писали:

А>>Пока не пришла в голову мысль о влиянии HT на приложение, я очень долго сидел в дебаггере и чесал репу, видя как, например, на пустом месте возникает access violation, причем другие потоки явно не влияют на указатель, по которому этот эксепшен происходит.

M> Угу. Очень типичная проблема. Для начала проверь следующие грабли:
M> — флажок IsMutliThread должен быть установлен (если нет — устанавливай его руками)
M> — все указатели и переменные, для которых возможно кроспотоковое использование должны записываться не простым присваиванием, а с помощью функций типа InterlockedExchange — это гарантирует от проблемы рассинхронизации процессорных кэшей.

Честно говоря, необходимость использования Interlocked-фукнций для всех присваиваний в этом контексте по крайней мере сомнительна.

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-фукнций для всех присваиваний в этом контексте по крайней мере сомнительна.

Для ВСЕХ переменных и не предлагается. Только для тех, которые могут изменяться и считываться разными потоками. Например, локальные переменные функций однозначно не могут быть использованы разными потоками, так как находятся в разных стеках.
Если переменная может изменяться одним потоком, а считываться другим, то это необходимомо.

С уважением Михаил Копачев

OAB>БД используешь?

нет

Здравствуйте, <Аноним>, Вы писали:

OAB>>БД используешь?

А>нет

какой делфи, много ли работы с VCL?

Здравствуйте, mkopachev, Вы писали:


M> Для ВСЕХ переменных и не предлагается. Только для тех, которые могут изменяться и считываться разными потоками. Например, локальные переменные функций однозначно не могут быть использованы разными потоками, так как находятся в разных стеках.
M> Если переменная может изменяться одним потоком, а считываться другим, то это необходимомо.

это называется конкурентный доступ и скорее всего реализованно. в делфях при работе с потоками основные проблеммы связанны с VCL и базами. там с многопоточностью напряг.

Здравствуйте, <Аноним>, Вы писали:

M>> Если переменная может изменяться одним потоком, а считываться другим, то это необходимомо.

А>32-битные чтения/записи гарантированно атомные, никаких синхронизаций не надо

это вы оптимизатору расскажете

7/7.1, VCL используется как доктор прописал — в главном потоке

Здравствуйте, Аноним, Вы писали:

M>> Если переменная может изменяться одним потоком, а считываться другим, то это необходимомо.

А>32-битные чтения/записи гарантированно атомные, никаких синхронизаций не надо

Щас.

Здравствуйте, mkopachev, Вы писали:

K>>Честно говоря, необходимость использования Interlocked-фукнций для всех присваиваний в этом контексте по крайней мере сомнительна.

M> Для ВСЕХ переменных и не предлагается. Только для тех, которые могут изменяться и считываться разными потоками. Например, локальные переменные функций однозначно не могут быть использованы разными потоками, так как находятся в разных стеках.
M> Если переменная может изменяться одним потоком, а считываться другим, то это необходимомо.

Это я к тому сказал, что Interlocked-фукнции всего лишь один из механизмов — а ошибки в межпотоковой синхронизации бывают очень разные.

Здравствуйте, mkopachev, Вы писали:


А>>>>Пока не пришла в голову мысль о влиянии 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...

Сделал уже — только так и работает