Потоки. Нужна ли синхронизация?

← →
Тын-Дын © (2008-06-17 23:56) [40]

> Поток изменил данные - послал сообщение, данные в буфере
> поменялись.

Так ещё раз - данные нужны основному потоку иногда.
Если получение данных будет происходить по инициативе доп. потоков, да ещё и массовым спамом сообщениями в основной поток, то основной поток совсем захлебнётся их обработкой. Я не прав?

← →
Тын-Дын © (2008-06-17 23:57) [41]

> ANB (17.06.08 22:21) [25]
>...
>то синхронизация убьет практически все преимущество
> от распараллеливания.

Это как раз та ситуация.

← →
ANB (2008-06-18 00:12) [42]

> то основной поток совсем захлебнётся их обработкой

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

← →
MsGuns © (2008-06-18 00:23) [43]

>Ну можно и глючно писать, без чтения умных книжек и тривиальной логики. >Оно стоит того?

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

>Ты забыл сказать про тип этого поля.
>В случае Boolean запись проходит атомарно.
>Если у тебя в поле целое число или строка, то глюки неизбежны.
>Хотя при Integer современные процессоры вроде бы теперь тоже атомарно >операции выполняют(присвоение).

тип - перечислимое (т.е. бул), но вот чего не могу понять А КАКАЯ РАЗНИЦА ? Ну прочитает гл.поток не полностью записанную строку (в случае стринга хотя бы), и что ? В чем глюк ? В том, что на секунду в соотв. строке сетки процессов отобразится что-то несуразное ? Где здесь криминал и чем этот "жестокий глюк" чреват для пользователя, который, скорее всего, в этот момент смотрит в чашку с кофе или считает ворон за окном ?

Вот не надо с умным лицом советовать делать табуретки натфилем и лобзиком

← →
Тын-Дын © (2008-06-18 00:50) [44]

> Дык не надо спамить. Если состояние потоков нужно редко,
> так и скидывать в основной поток их надо пореже.

Пореже - это как?
В некоторый момент времени основному потоку понадобились данные. Как он узнает, актуальны ли данные, полученные от потоков?

> MsGuns © (18.06.08 00:23) [43]

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

Вот потому, что -
> тип - перечислимое (т.е. бул),

Не бул, а байт. (Кстати, размер BOOL - 4 байта, Boolean - 1 байт).

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

> Ну прочитает гл.поток не полностью записанную строку (в
> случае стринга хотя бы), и что ? В чем глюк ? В том, что
> на секунду в соотв. строке сетки процессов отобразится что-
> то несуразное ?

Ну если тебе в данный момент всё равно, что получаемые данные чушь, то кто ССЗБ?

> Вот не надо с умным лицом советовать делать табуретки натфилем
> и лобзиком

Исходя из высказывания в пред. абзаце я бы посоветовал, как многие тут, метлу в руки, но не буду. Сам бы убил за такие советы (советы другим, не себе. Мне-то всё равно).
Знание - сила. Лучше иногда теорию читать и на практике использовать.
"Метод тыка" - это хорошо, конечно, но иногда может привести к непредсказуемым последствиям.

← →
Palladin © (2008-06-18 09:34) [45]

> Тын-Дын © (17.06.08 22:09) [23]

Очень увлекательные комметарии, вот только не в ту степь и не в тему. Вот ты талдонишь о том что единственное правильное решение использовать критические секции. Замечательно. Заметь, я нигде этого не опровергал, лишь заметил, что в можно отработать и через SendMessage, ничего в этом криминального нет. Ну это ладно. Начнем издалека. Ответь на вопрос: какова цель использования критических секций?

← →
MsGuns © (2008-06-18 09:45) [46]

>Тын-Дын © (18.06.08 00:50) [44]

Ты случаем не академик ? А то стиль вещания очень академический: мол делай как я сказал - иначе могила.

← →
ANB (2008-06-18 10:19) [47]

> лишь заметил, что в можно отработать и через SendMessage

Все верно. Это всего лишь другой подход к синхронизации. Позволяет обойтись без критических секций (во всяком случае - своих).
Это я для Тын-Дын ©.

А вот если синхронизация начинает тормозить работу, вот тогда надо использовать что то другое. Например - PostMessage или вот надо попробовать методу МсГанса.

> MsGuns © (18.06.08 09:45) [46]

Милин, а почему когда я попробовал так делать, у меня AV лезли ?

← →
Тын-Дын © (2008-06-18 12:41) [48]

> Palladin © (18.06.08 09:34) [45]
>
> > Тын-Дын © (17.06.08 22:09) [23]
>
> Очень увлекательные комметарии, вот только не в ту степь
> и не в тему. Вот ты талдонишь о том что единственное правильное
> решение использовать критические секции. Замечательно. Заметь,
> я нигде этого не опровергал, лишь заметил, что в можно
> отработать и через SendMessage, ничего в этом криминального
> нет. Ну это ладно. Начнем издалека. Ответь на вопрос: какова
> цель использования критических секций?

Очень снобский пост, однако.
Давай дальше поговорю (Кстати, "талдонить" - нет такого слова. Есть слово "Талдычить". Это так, для сведения).

Ещё раз утверждаю, что здесь не обойтись без системных средств синхронизации. В данном случае именно без критических секций.

Выше (если ты удосужился прочитать) написано, почему не подходят обмен сообщениями SendMessage. но упереться рогом в землю и повторять одно и то же, игнорируя очевидные факты - видимо твой стиль.

> Ответь на вопрос: какова цель использования критических
> секций?

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

> MsGuns © (18.06.08 09:45) [46]
> >Тын-Дын © (18.06.08 00:50) [44]
>
> Ты случаем не академик ? А то стиль вещания очень академический:
> мол делай как я сказал - иначе могила.

Нет, не академик. Но то, о чем говорю, знаю. А не игнорирую, как ты, логику и опыт.

> ANB (18.06.08 10:19) [47]
>
> > лишь заметил, что в можно отработать и через SendMessage
>
> Все верно. Это всего лишь другой подход к синхронизации.
> Позволяет обойтись без критических секций (во всяком случае
> - своих).
> Это я для Тын-Дын ©.

Ну я ж написал выше, почему нельзя использовать SendMessage(как и PostMessage). Это может быть верно для единственного дополнительного потока.

> Милин, а почему когда я попробовал так делать, у меня AV
> лезли ?

Ну так всё верно. Если многопоточная программа написана неправильно - AV и будут. В лучшем случае.

← →
Игорь Шевченко © (2008-06-18 12:56) [49]

Вы б хоть автора послушали, что ли, прежде чем копья ломать.
Все зависит от задачи и методы чтения переменных тоже.

← →
Palladin © (2008-06-18 13:07) [50]

> Тын-Дын © (18.06.08 12:41) [48]

Какой неудержимый поток мыслей. :) И не лень ведь писать... Я всего лишь задал тебе вопрос, на кой ляд нужны критические секции? Цель их использования какая? Ликбез мне не нужен. Кратко ответить я так понял ты не можешь.

Для монопольного доступа к каким либо разделяемым ресурсам они нужны. Второй вопрос, зачем нам этот монопольный доступ? В одном случае, что бы считать данные, в другом, что бы считать/записать. Зачем главному потоку считывать данные? Что бы отобразить. Каким попом это будет происходить? Критические секции не занимаются отображением данных. Как их (данные) отображать? Всю ветку ты распинаешься про КС, а о том как же данные отобразить, когда их отобразить, так ничего и не сказал, кроме того, что нужно нажимать на кнопку. Вопрос то читал?

> Ещё раз утверждаю, что здесь не обойтись без системных средств
> синхронизации.

Еще раз утверждаю, что я не утверждаю обратное. Всеми руками за! Ты можешь понять такую простейшую мысль, что мой пост про таймеры и отдельный поток-монитор, подсказывают как отображать периодически?
Противопоказаний к использованию SendMessage, вот честно, не вижу. Огромные посты к этому не предрасполагают. Если не трудно, тыкни носом.

← →
Sapersky (2008-06-18 13:37) [51]

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

Хм, интересно, откуда такая разница между байтом и Integer? Процессоры уже давно как минимум 32-битные, т.е. никакой разницы в атомарности быть не должно. Ну может быть, от выравнивания зависит, хотя здесь точно не в курсе (зависит от того, как операции с невыровненными данными разбиваются на две - на уровне процессора или компилятора).
AFAIK, чтение Integer - потокобезопасно, при условии, что пишет его один поток (или несколько с использованием Interlocked), за исключением некоторых моментов, относящихся к многопроцессорным/многоядерным машинам:
http://msdn.microsoft.com/en-us/library/ms686355(printer).aspx

Начиная с P1, есть команда процессора, позволяющая атомарно модифицировать или прочитать 8 байт (cmpxchg8b), на ней основаны 64-битные Interlocked-функции последних версий Windows. Впрочем, Interlocked-функции можно писать и самостоятельно:
http://msdn.microsoft.com/en-us/magazine/cc302329(printer).aspx
и использовать в любой Win. Для Дельфи:
http://qc.borland.com/wc/qcmain.aspx?d=6212

← →
Тын-Дын © (2008-06-18 13:38) [52]

> Palladin © (18.06.08 13:07) [50]

> Для монопольного доступа к каким либо разделяемым ресурсам
> они нужны.

И всё? тогда точно ликбез не повредит.

Для чего нужен монопольный доступ? - Это лишь средство записать или получить корректные данные, т.е. согласованные логически.

Когда речь идёт об одном дополнительном потоке, вопросов нет - можно использовать и SendMessage, так как этот поток может предоставить другому потоку полностью согласыванные данные (я могу даже дать пример синхронизации БЕЗ средств синхронизации ядра).
Если же речь идет о получении согласованных данных нескольких потоков в некоторый момент времени, то здесь речи быть не может о SendMesage, так как
1. Основной поток должен получить изменённые данные в тот момент, когда это нужно ему, а не доп. потоку.
2. Выше написано, что данные от разных потоков могут быть рассогласованы.

> можешь понять такую простейшую мысль, что мой пост про таймеры
> и отдельный поток-монитор, подсказывают как отображать периодически?
>

Тебя спрашивали об этом?

> Противопоказаний к использованию SendMessage, вот честно,
> не вижу

Читай выше.

> Огромные посты к этому не предрасполагают. Если не трудно,
> тыкни носом.

Нет уж. Прежде чем воду лить, потрудись прочитать.

И почитай уже какую-нибудь книжку, что-ли. Для самообразования.

← →
Тын-Дын © (2008-06-18 13:41) [53]

> Sapersky (18.06.08 13:37) [51]
> Работа с байтом - всегда атомарная операция, потому до сих
> пор и не возникало проблем. Замени на Integer - получишь
> проблемы очень скоро.
>
> Хм, интересно, откуда такая разница между байтом и Integer?
> Процессоры уже давно как минимум 32-битные, т.е. никакой
> разницы в атомарности быть не должно.

А как насчет операций суммирвания и прочих? они тоже атмарные?
int1 := ((int2 div 8) + Int3)*int4;

← →
Sapersky (2008-06-18 14:30) [54]

В контексте многопоточности говорить о сложении-вычитании смысла нет. Имеет значение:
1) Чтение или запись (+ сколько потоков пишет)
2) Размер данных (+ связаны ли данные)
Что вы хотели показать своим примером? Там есть и чтение и запись, но какая переменная к какому потоку относится, сколько потоков выполняют этот код - не уточнено.

← →
Leonid Troyanovsky © (2008-06-18 14:47) [55]

> oxffff © (17.06.08 22:35) [27]

> Поток чтения может обращаться к shared данным напрямую.

Может. Например, FTerminated во-ще ничем не защищено.

> Если нет зависимого чтения, то InterLocked* не нужны.

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

Слишком много "если" для Начинающим.
Зависимы ли опрашиваемые данные - это еще вопрос.

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

--
Regards, LVT.

← →
MsGuns © (2008-06-18 15:35) [56]

Блин, я ему про Фому, а он про Ерему. Какая критичность может быть в той схеме, что я описал ? Если каждый поток СОЗДАЕТ СВОЙ РЕКОРД, адрес которого добавляет в список всех рекордов (единственное, что нуждается в синхронизации) - никто другой не должен туда ПИСАТЬ. А ЧИТАЕТ оттуда гл.поток, который использует этот рекорд для извлечения данных для отображения. Если гл.поток сунется (по таймеру) в рекорд ДО ТОГО, КАК ПОТОК ЗАКОНЧИТ ТУДА ЗАПИСЬ, то в худшем случае отобразится не вся информация, а ее "кусок", что проявится только в том случае если эта запись содержит какие-нибудь огроменные объекты типа списков или массивов - но я вот ума не приложу зачем эту офигень ОТОБРАЖАТЬ ? Причем тут сихронизация, а тем более какие-то КС ? Где может быть AV, если с одного места пишется, а с другого читается ОДИН И ТОТ ЖЕ участок памяти ? Где тут взоврется ?
А глюки могут быть, конечно. Если, к примеру, запутать потоки, заставив их обращаться не к "своим" записям - но это данном случае трудно сделать нечаянно.

PS Справка знатокам русского языка.
Наряду с глаголом "талдычить" есть еще "долдонить" - слово вполне литературное и отличается от первого тем, что употребляется когда хотят сказать, что не просто "талдычат" (т.е. повторяют одну и ту же фразу или мысль), а еще стучат по голове непонятливому,- иногда в буквальном смысле.
Слово же "талдонить" суть производное и вполне может существовать в местных диалектах.

Одно слово - академик ;)

← →
Тын-Дын © (2008-06-18 16:20) [57]

> PS Справка знатокам русского языка.
> Наряду с глаголом "талдычить" есть еще "долдонить" - слово
> вполне литературное и отличается от первого тем, что употребляется
> когда хотят сказать, что не просто "талдычат" (т.е. повторяют
> одну и ту же фразу или мысль), а еще стучат по голове непонятливому,
> - иногда в буквальном смысле.
> Слово же "талдонить" суть производное и вполне может существовать
> в местных диалектах.

Вот блин, и этот про Фому.
Так "талдонить" или "долдычить"?
Читать умеешь?

PS.

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

← →
MsGuns © (2008-06-18 16:47) [58]

>Тын-Дын © (18.06.08 16:20) [57]
>Не пиши больше бред про синхронизацию, пожалуйста, признавая, что ты сам >получаешь вместо данных из потоков бред.
>Если тебя это устраивает - это твои личные тараканы. Не надо размножать их в инете.

Экой ты смешной, друже ;) Устраивает не меня, а пользователей, и написанное вовсе не бред. На бред больше похожи твои теоретические изыски под девизом "так делать низзя ибо будет бо-бо", к сабжу имеющие весьма отдаленное отношение.

Если ты хочешь рассказать про синхронизацию и, особенно, про КС (а ведь тебя просили !), то либо расскажи и просвяти неучей, либо не "размножай в инете" свои домыслы.

← →
Тын-Дын © (2008-06-18 17:25) [59]

> Если ты хочешь рассказать про синхронизацию и, особенно,
> про КС (а ведь тебя просили !),

А я написал свои домыслы палладину. Мало разве?

> Экой ты смешной, друже ;) Устраивает не меня, а пользователей,
> и написанное вовсе не бред.

Понимаешь, твой частный случй - это именно частныйслучай.
Ты же пытаешься распространить его на общее, что является категорически неправильным и вредным.

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

Мои практические советы имеют к теме топика самое непосредственное отношение (В отличие от твоих отвлечённых -"В моей программе так работает"ю А вот у ANB - не работает так. Почему бы это?).

← →
MsGuns © (2008-06-18 19:59) [60]

>Тын-Дын © (18.06.08 17:25) [59]
>Понимаешь, твой частный случй - это именно частныйслучай.
>Ты же пытаешься распространить его на общее, что является >категорически неправильным и вредным.

? Читаем мой пост, который вызвал у тебя такую реакцю:

>MsGuns © (17.06.08 12:51) [4]
>Потоки пишут в кэши через Synchronize (хотя, возможно, это и не обязательно)

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

>Мои практические советы имеют к теме топика самое непосредственное >отношение

ИМХО, мой пример более непосредственно относится именно к топику (по крайней мере как я его понял) именно как частный случай, который не требует сложного кода с кучей try except/finally и реализуется по весьма тривиальной схеме - потоки сами по себе что-то пишут в свои собственные переменные, а гл. поток периодически ревизует эти переменные и в соответствии с ними отображает текущий статус потока (или точнее, шал алгоритма, которым занимается поток в данный момент времени) напрмер, в сетке.
Для начинающего это много проще и не требует капитального въезжания в сам процесс синхронизации, который интуитивно малопонятен человеку, не знакомому с принципами работы процессора и ОС

Этот метод при правильной организации памяти (например, через "кэши"-рекорды, "принадлежащие" активным потокам) вполне надежен и если в кэши не пихать килобайты мусора, маловероятно что будет показывать "сырую" (вот еще чудо-термин,- а что, бывает "сваренная" или "сухая" инфа ?) информацию. Визуально, по крайней мере, это незаметно.

← →
MsGuns © (2008-06-18 20:16) [61]

А вот другая схема, построенная не на опросе "мамы" деток", а на оповещении "детками" "мамы" о завршении ими какого-то целостного блока алгоритма:
В этом случае главный поток ("мама") никого не опрашивает (ессно, таймер тут побоку), а вот потоки ("дочки") по завершению блока сообщают об этом событии "маме". Вот тут как раз нужны и КС и синхронизация дабы "доклады" "деток" не "перепутывались". Но в этом случае "мама" будет весьма в затруднительном положении - каким образом ей перерисовывать на канве ту же сетку, если "доклады" будут сыпаться как из Рога изобилия - сетка просто будет безбожно моргать либо периодически подмаргивать, что будет не просто заметно визуально - это будет раздражать глаза.
Именно поэтому в ДАННОМ случае я и выбрал систему опроса, а не оповещения.
Вот если бы визуализации не было (например, если идет мониторинг запросов к скл-серверу, но отображаются только завершенные процессы), а вместо этого "мама" должна была бы сделать что-то невизуальное, но своевременное (например послать сообщение об изменении статуса запроса по сети) - вот тогда да, метод "опроса" глючен по своей сути, и вместо него следует применить метод "оповещения".

← →
Игорь Шевченко © (2008-06-18 23:40) [62]

Вам бы сказки писать - Шарль Перро в гробу бы перевернулся от зависти.

"Есть приложение, в котором выполняются несколько потоков. Каждый поток имеет свой локальный набор переменных. Требуется периодически считывать из главного потока значения некоторых локальных переменных этих потоков (сбор статданных, для последующего отображения статистики на экране).
Вопрос. Надо ли помещать в критическую секцию процесс чтения локальных переменных главным потоком из остальных потоков?
ps прочитал пару статей по потокам, но там в основном рассматриваются варианты, когда потоки пытаются изменять, а не читать общие переменные"

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

← →
MsGuns © (2008-06-19 09:16) [63]

>Игорь Шевченко © (18.06.08 23:40) [62]
>Вам бы сказки писать - Шарль Перро в гробу бы перевернулся от зависти.

Да ты, Игорь, тоже не пальцем делан :)

← →
Игорь Шевченко © (2008-06-19 09:40) [64]

MsGuns © (19.06.08 09:16) [63]

Серега, смотри сам - если у тебя, допустим, N потоков занимаются, ну скажем закачкой файлов и в "локальных переменных" хранят прогресс этой самой закачки, а главный поток натурально этот прогресс в красивом виде отображает. Неужели в этом случае требуется супер-пупер синхронизация с критическими или некритическими секциями ?

← →
vint45 (2008-06-19 12:34) [65]

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

1. Кто-то просил уточнить, что делают доп. потоки.
Потоки занимаются файловыми операциями. Соответственно, вычислительная нагрузка на процессор для каждого потока достаточно мала. Каждый поток работает со своим файловым источником, и с другими доп. потоками не взаимодействует (нет никаких общих ресурсов)

2. Главная задача состоит в корректном (синхронизированном) копировании значений переменных доп. потоков к основному потоку приложения (передача статданных в основной поток для последующего отображения в форме главного потока).
Копирование значений переменных абы как, без синхронизации, или согласованности (не знаю как правильнее сказать, т.е. без проверки на то, что будут скопированы реальные значения переменных) считаю неправильным.

3. Теперь о КС. В моем понимании это секция кода, которая может выполняться только одним потоком. Я не совсем понимаю как КС можно использовать при передаче переменных без коллизий. Ведь КС по сути призваны упорядочить обращение потоков к одному куску кода, но ведь здесь и нет никакого обращения разных потоков к одному коду.
Допустим мы процедуру присвоения переменных от доп. к основному потоку с КС вызываем из основного потока. Так как доп. потоки при выполнении этой КС простаивать не будут(так сами не вызывают эту КС), то они вполне могут начать запись в свои переменные в момент присвоения и переменным главного потока может присвоиться абракатабра.
Если процедуру присвоения с КС вызывать из доп. потоков, то тоже возникают коллизии. Так как основной поток в момент вызова КС доп. потоком также простаивать не будет, и может возникнуть ситуация, когда при присвоении переменным новых значений, осн. поток одномоментно будет считывать их значения, и опять возникнут коллизии.

4. О Событиях. Опять же в моем понимании, в общем случае событие это механизм позволяющий приостановить работу всех потоков процесса, кроме потока, который инициировал ожидание этого события.
Поэтому, если мы будем инициировать ожидание события из основного потока, то получаем остановку выполнения всех доп. потоков, и делаем опять же через основной поток считывание переменных. Но так как переменные в доп. потоках в этот момент не синхронизированы, то мы можем считать абракатабру.
При вызове ожидания события из доп. потоков, все проходит вроде как шоколадно. Доп. поток вызывает ожидание, пишет синхронизированные данные в переменные основного потока, и после этого вызывает само событие, запускающие остальные потоки. Здесь смущает только то, что основной поток (да и остальные) будет часто простаивать, так как доп. потоков может быть не мало. И этот простой может оказаться критичным с точки зрения управления приложением.

← →
DVM © (2008-06-19 12:44) [66]

> но ведь здесь и нет никакого обращения разных потоков к
> одному коду.

Как нет? Основной поток опрашивает переменные дополнительного.

← →
DVM © (2008-06-19 12:45) [67]

> Так как доп. потоки при выполнении этой КС простаивать не
> будут(так сами не вызывают эту КС)

так надо сделать, чтобы тоже они работали через крит секцию иначе труба.

← →
DVM © (2008-06-19 12:55) [68]

> vint45

Я не понимаю, в чем проблема сделать так, чтобы внутри метода Execute обращение к переменным было реализовано через свойства, защищенные КС.

interface uses Classes, SyncObjs; type TTestThread = class(TThread) private FParam: integer; FCriticalSection: TCriticalSection; procedure SetParam(AParam: integer); function GetParam: integer; protected procedure Execute; override; public constructor Create(CreateSuspended: boolean); destructor Destroy; override; prorerty Param: integer read GetParam write SetParam; end; implementation constructor TTestThread.Create(CreateSuspended: boolean); begin FCriticalSection := TCriticalSection.Create; inherited Create(CreateSuspended); end; destructor TTestThread.Destroy; begin FCriticalSection.Free; inherited Destroy; end; procedure TTestThread.SetParam(AParam: integer); begin FCriticalSection.Enter; try FParam := AParam; finally FCriticalSection.Leave; end; end; function TTestThread.GetParam: integer; begin FCriticalSection.Enter; try result := FParam; finally FCriticalSection.Leave; end; end; procedure TTestThread.Execute; begin Param := 0; while not Terminated do begin Param := Param + 1; sleep(100); end; end;

>Игорь Шевченко © (19.06.08 09:40) [64]

Подходит схема "опроса", т.е. КС и снхронизация не обязательны (и даже могут быть вредны, ибо тормозят)

> Игорь Шевченко © (19.06.08 09:40) [64]
> MsGuns © (19.06.08 09:16) [63]
>
> Серега, смотри сам - если у тебя, допустим, N потоков занимаются,
> ну скажем закачкой файлов и в "локальных переменных" хранят
> прогресс этой самой закачки, а главный поток натурально
> этот прогресс в красивом виде отображает. Неужели в этом
> случае требуется супер-пупер синхронизация с критическими
> или некритическими секциями ?

Не супер-пупер, а обычная синхронизация требуется.

> MsGuns © (19.06.08 14:31) [69]
> >Игорь Шевченко © (19.06.08 09:40) [64]
>
> Подходит схема "опроса", т.е. КС и снхронизация не обязательны
> (и даже могут быть вредны, ибо тормозят)

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

> vint45 (19.06.08 12:34) [65]

> 2. Главная задача состоит в корректном (синхронизированном)
> копировании значений переменных доп. потоков к основному
> потоку приложения (передача статданных в основной поток
> для последующего отображения в форме главного потока).
> Копирование значений переменных абы как, без синхронизации,
> или согласованности (не знаю как правильнее сказать, т.
> е. без проверки на то, что будут скопированы реальные значения
> переменных) считаю неправильным.

Так тебе получать данные нужно по инициативе основного потока, или все же передавать информацию из доп. потоков?

От этого зависит подход к решению задачи.

← →
vint45 (2008-06-19 15:14) [71]

> DVM © (19.06.08 12:55) [68]

В твоем примере чтение и запись свойства происходит через одну и ту же КС. Соответственно чтение и запись одновременно выполняться не могут. Т.е. если основной поток будет пытаться считать значение свойства, то доп. поток будет ожидать записи нового значения и наоборот, т.о. коллизий не возникнет.
А меня клинило, думал что одну и ту же КС можно вызвать внутри только одной процедуры.

> Тын-Дын ©

Мне важно выполнять корректное присвоение переменным основного потока. Каким образом это лучше сделать (получать данные основным потоком или доп. потоками), я пока не знаю. Хотя DVM привел, на мой взгляд, хороший пример.

> vint45 (19.06.08 15:14) [71]

> Соответственно чтение и запись одновременно выполняться
> не могут.

Так это и требуется. Иначе бардак будет.

Тын-Дын © (19.06.08 14:36) [70]

> Не супер-пупер, а обычная синхронизация требуется.

Нахрен не сдалась.

Мы не в синагоге, нам кошерность не требуется, а требуется решение задачи. Каковая задача до сих в пор в понятном виде не озвучена.

> Мы не в синагоге, нам кошерность не требуется, а требуется
> решение задачи. Каковая задача до сих в пор в понятном виде
> не озвучена.

Требуется не кошерность, а тривиальное - неразрушенные данные.
Без синхронизации (любым способом) этоневозможно. За исключением записи и чтения переменных размером в 1 байт.

Тын-Дын © (19.06.08 15:41) [74]

> Требуется не кошерность, а тривиальное - неразрушенные данные.

Еще раз, медленно и печально. Допустим, есть несколько потоков, занимающихся закачкой файлов. Для каждого файла известен его полный размер и размер текущего закаченного содержимого. Каждый файл качается своим потоком, соотв. оба размера являются локальными переменными этого потока. Еще один поток (главный, неглавный, неважно) занимается отображением прогресса скачивания файлов (Napster или FlashGet или eMule или Torrent видел ? - так вот у бабочек то же самое).
Соответственно, этот поток опрашивает локальные переменные (размер скачанной части) каждого потока и красиво выводит в Progress bar, можно даже с градиентом.

Локальные пременные могут быть длиной либо 32 бита, либо 64.

Какие тут могут быть разрушенные данные ?

> MsGuns ©

> Игорь Шевченко ©

Для демонстрации схематичный пример потока.

type TCopier=class(TThread) private FSize: int64; //Размер всех скопированных файлов LastFileSize: int64; //Размер последнего скопированного файла LastFileName: String; //Имя последнего скопированного файла procedure Copy; //Процедура копирования protected procedure Execute; override;

Данные (Например, Private-Fields)из нескольких запущенных потоков должны попадать в основной поток и отображаться, затем сохраняться в журнал (основной поток).

Без синхронизации всякие размышления об этом бесмысленны.

> Еще раз, медленно и печально.

Можно побыстрее и не так печально. Смысл от этого не изменится. и необходимость в синхронизации тоже.
Игорь, тебе-то уж об этом задумываться - нужно-не нужно... Даже неудобно как-то.

>
> Просьба на [75] ответить

Я на [75] в [76] ответил.

Тын-Дын © (19.06.08 15:52) [78]

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

качающий поток:
type
size_t = int64;

TDownloadThread = class(TThread)
private
FTotalSize: size_t;
FCurrentSize: size_t;
.........
public
property TotalSize: size_t read FTotalSize;
property CurrentSize: size_t read FCurrentSize;
.......
end;

меняется в процессе загрузки, сам понимаешь, только FCurrentSize;

Потоки. Нужна ли синхронизация? Найти похожие ветки