Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Потоки. Нужна ли синхронизация? [D6, XP]

Страницы: < 1 2 3 4 5 6 7 >
vint45 © (2008-06-17 12:42:00)
Здраствуйте. Есть приложение, в котором выполняются несколько потоков. Каждый поток имеет свой локальный набор переменных. Требуется периодически считывать из главного потока значения некоторых локальных переменных этих потоков (сбор статданных, для последующего отображения статистики на экране).
Вопрос. Надо ли помещать в критическую секцию процесс чтения локальных переменных главным потоком из остальных потоков?
ps прочитал пару статей по потокам, но там в основном рассматриваются варианты, когда потоки пытаются изменять, а не читать общие переменные.

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

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

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

Тын-Дын (2008-06-18 16:20:00) [82]

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

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

PS.

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

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

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

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

Leonid Troyanovsky (2008-06-18 14:47:00) [84]

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

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

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

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

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

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

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

--
Regards, LVT.

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

Тын-Дын (2008-06-18 13:41:00) [86]

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

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

Тын-Дын (2008-06-18 13:38:00) [87]

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

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

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

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

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

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

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

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

Читай выше.

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

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

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

Sapersky (2008-06-18 13:37:00) [88]
Работа с байтом - всегда атомарная операция, потому до сих пор и не возникало проблем. Замени на 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

Palladin (2008-06-18 13:07:00) [89]

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

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

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

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

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

Игорь Шевченко (2008-06-18 12:56:00) [90]
Вы б хоть автора послушали, что ли, прежде чем копья ломать.
Все зависит от задачи и методы чтения переменных тоже.

Тын-Дын (2008-06-18 12:41:00) [91]

> 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 и будут. В лучшем случае.

ANB (2008-06-18 10:19:00) [92]

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

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

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

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

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

MsGuns (2008-06-18 09:45:00) [93]
>Тын-Дын © (18.06.08 00:50) [44]

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

Palladin (2008-06-18 09:34:00) [94]

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

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

Тын-Дын (2008-06-18 00:50:00) [95]

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

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

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

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

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

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

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

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

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

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

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

MsGuns (2008-06-18 00:23:00) [96]
>Ну можно и глючно писать, без чтения умных книжек и тривиальной логики. >Оно стоит того?

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

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

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

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

ANB (2008-06-18 00:12:00) [97]

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

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

Тын-Дын (2008-06-17 23:57:00) [98]

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

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

Тын-Дын (2008-06-17 23:56:00) [99]

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

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

ANB (2008-06-17 23:54:00) [100]

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

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

Кнопочка и таймер - не противоречат друг другу.

А согласованность данных при многопоточных вычислениях - тады уж лучше и не устраивать многопоточность.

Страницы: < 1 2 3 4 5 6 7 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »