Форум: "Основная";
Текущий архив: 2004.02.06;
Скачать: [xml.tar.bz2];
ВнизThread-safe код - это как? Найти похожие ветки
← →
aldor (2004-01-23 17:53) [0]Цитата из help"а:
"If ServerType is stThreadBlocking, make sure that all code in an OnClientDisconnect event handler is thread-safe"
Что значит "thread-safe"?
← →
Юрий Зотов (2004-01-23 18:14) [1]Потокобезопасный. То есть, нормально работающий в нескольких потоках одновременно.
← →
aldor (2004-01-24 01:31) [2]> Потокобезопасный. То есть, нормально работающий в нескольких потоках одновременно.
:)))))))))
В чем выражается потокобезопасность? Каким образом я должен строить код в этих функциях?
← →
kull (2004-01-24 01:33) [3]Ну наверное через Critical Section или другие синхронизирующие объекты. Зависит от задачи...
← →
Palladin (2004-01-24 01:52) [4]
> aldor © (24.01.04 01:31) [2]
какой смешливый
потокобезопасный код означает:
1 исполнение в нескольких потоках (TThread или функции WinAPI)
2 контроль доступа к ресурсам использющихся в этом коде (память, файлы, etc.)
пример: файлы
смысл кода:
ляля1
открыть файл
считывание данных
запись данных
закрытие файла
ляля2
он потоконебезопасный ибо не блокирует ресурс(файл) при работе с ним. работают два запущенных потока с таким кодом, если они оба начнут работать с файлом его содержимое будет абсолютно не предсказуемо
блокировка ресурсов например TCriticalSection + F1 и See Also
← →
y-soft (2004-01-24 10:04) [5]>aldor © (24.01.04 01:31) [2]
>> Потокобезопасный. То есть, нормально работающий в нескольких потоках одновременно.
:)))))))))
Смех без причины - ... :|
В Delphi VCL, кстати, код не является потокобезопасным
Потокобезопасность достигается исключением одновременного доступа из разных потоков к совместно используемым ресурсам
Достичь этого можно 2-мя способами:
1. Блокировать ресурс на время использования потоком
- использование функций InterlockedXXX
- использование объектов синхронизации
2. Упорядочить вызов функций, осуществляющих такой доступ
- постановка операций доступа в очередь (посылка сообщений окну, APC, очереди COM+, событийный интерфейс и т.д.)
← →
Digitman (2004-01-24 13:13) [6]
> aldor © (23.01.04 17:53)
эдакая "мягкая" ассоциация (лишь в общих чертах приводимая) к термину thread-safe - басня И.А.Крылова "Лебедь, рак и щука" ... помнишь такую ? ... персонажи там тащат некое транспортное средство одновременно в разные стороны, а "воз и ныне там" ! ... ИванАндреичу простительно : будучи незнакомым с концепцией невытесняющей мультизадачности и мультипоточности ОС на базе Win32, он не предвидел плачевный результат этого - крушение телеги, ограничившись лишь назидательной моралью о том, что телега поедет в нужную сторону лишь в том случае, когда персонажи будут тащить ее либо по очереди (каждый в свою сторону) либо все вместе в одну и ту же выбранную сторону
← →
Aldor (2004-01-24 15:48) [7]> какой смешливый
Ну а почему не повеселиться - абсолютно точный ответ на вопрос, я, скорее всего, ответил бы также, отсюда и улыбка.
Благодарен за все ответы, разобрался.
← →
Verg (2004-01-24 16:19) [8]Раньше это называлось реентерантностью кода. Т.е. при кодировании процедуры необходимо учитывать, что она может быть вызвана снова в любой точке (времени) своего выполнения и совершенно с другими параметрами.
Простейшее правило - не использовать или использвать по правилам ОС (например, крит. секции) глобальные переменные.
← →
vuk (2004-01-24 16:34) [9]to Verg:
>Раньше это называлось реентерантностью кода.
Называется это реентерабельностью и никуда не делось. Потокобезопасность - это несколько иное. И проблемы там другие решаются, нежели при достижении реентерабельности кода. Код может быть хоть сто раз реентерабельным но ни разу не потокобезопасным.
← →
Verg (2004-01-24 16:58) [10]
> vuk © (24.01.04 16:34) [9]
> Код может быть хоть сто раз реентерабельным но ни разу
> не потокобезопасным.
Ну что ж, это очень информативно.
Так разъясните уж в чем же принципиальная разница.
← →
Verg (2004-01-24 17:02) [11]Ну или пример, что ли, "сто раз реентерабельного", но потоконебезопасного кода.
Просто даже интересно.
← →
vuk (2004-01-24 17:16) [12]>Так разъясните уж в чем же принципиальная разница.
Пример. В процедуре создаем и используем именованный FileMapping. Реентерабельно? Да, не вопрос. Потокобезопасно? Нет.
Реентерабельность - неизменность функционирования кода при его повторном вызове (re-enter) до завершения предыдущего вызова и относится к одной процедуре и ее методике работы со своими внутренними данными. В частности реентерабельностью должны обладать рекурсивные процедуры. Простейший пример - QuickSort.
Потокобезопасность - нормальное функционирование в условиях конкуренции за ресурсы. Здесь обычно рассматриваются разные потоки и процессы и их взаимодействие.
← →
Verg (2004-01-24 17:44) [13]
> Пример. В процедуре создаем и используем именованный FileMapping.
> Реентерабельно? Да, не вопрос. Потокобезопасно? Нет.
Это неубедительно и это спорно.
Это может быть так же нереентерабельно как и непотокобезопасно.
Все зависит от задачи.
Понятие потоко-безопасного кода порождено собственно методом реализации потоков. А именно, так или ниаче, это аппаратное прерывание в системах с распределением времени (вытесняющая многозадачность).
Т.е., если упрощенно, то обработчик прерывания, который при входе разрешил аппаратные прерывания процессору и контроллеру, должен быть готов к тому, что во время его работы прерывание, обработчиком которого он и является, может возникнуть снова. Его и называют реентерабельным. Если же он к этому не готов полность или частично, то он должен запретить (или не разрешать) повторные входы в него или в некоторый участок его кода ( запрет аппаратных прерываний - читай критические секции).
Этот принцип организации многопоточности делает потоки по-сути очень близкими к обработчикам прерываний в смысле построения кода.
С другой стороны, например, наличие потоков в системах реального времени не накладывает же требований к "потоко-безопасности"/реентерабельности, но однако при этом так же существует конкуренция за общие системные ресурсы.
← →
Verg (2004-01-24 17:50) [14]
> В частности реентерабельностью должны обладать рекурсивные
> процедуры.
А это вообще из другой оперы.
Рекурсивность НЕ подразумевает реентерабельности (кстати, спасибо за поправку:).
Рекурсивная процедура вызывает себя повторно в предсказуемые, строго заданные ее же алгоритмом мометы (точки) своего выполнения.
← →
vuk (2004-01-24 17:56) [15]>Это неубедительно и это спорно. Это может быть так же
>нереентерабельно как и непотокобезопасно.
Все переменные храним в стеке. Причины нереентерабельности назовите.
>Понятие потоко-безопасного кода порождено собственно методом
>реализации потоков.
А если система многопроцессорная и потоки крутятся на разных процессорах? :o)
← →
vuk (2004-01-24 18:01) [16]>А это вообще из другой оперы.
Из той же. Рекурсия - частное проявление реентерабельности.
← →
Verg (2004-01-24 18:11) [17]
> vuk © (24.01.04 17:16) [12]
> >Так разъясните уж в чем же принципиальная разница.
> Пример. В процедуре создаем и используем именованный FileMapping.
> Реентерабельно? Да, не вопрос. Потокобезопасно? Нет.
Тут про способ хранения/использования переменных ни слова....
> Все переменные храним в стеке. Причины нереентерабельности
> назовите.
Так, ну "рояль в кустах" или "туз в рукаве" или все же зачем-то
именованный FileMaping?
Verg (C)
> Простейшее правило - не использовать или использвать по
> правилам ОС (например, крит. секции) глобальные переменные.
> А если система многопроцессорная и потоки крутятся на разных
> процессорах? :o)
Да хоть так. Сути дела это не меняет.
Не, серъезно, подумайте об этом еще раз.
← →
Verg (2004-01-24 18:13) [18]
> Из той же. Рекурсия - частное проявление реентерабельности.
Значит мы с вами используем один термин (слово) для обозначения разных по сущности свойств кода.
← →
vuk (2004-01-24 18:26) [19]>Тут про способ хранения/использования переменных ни слова....
Каюсь, забыл упомянуть об этом. Думал, что это очевидно.
>Так, ну "рояль в кустах" или "туз в рукаве" или все же зачем-то
>именованный FileMaping?
Например, для передачи данных между процессами.
Так что с причинами нереентерабельности?
>Да хоть так. Сути дела это не меняет.
Правда? То есть два потока на одном процессоре - это то же самое, что и два потока на двух процессорах? Или все-таки это уже не только разделение времени?
← →
vuk (2004-01-24 18:35) [20]Reentrant
----------------
A computer program or routine is described as reentrant if it is designed such that a single copy of the program"s instructions in memory can be shared by multiple users or separate processes. The key to the design of a reentrant program is to ensure that no portion of the program code is modified by the different users/processes, and that process-unique information (such as local variables) is kept in a separate area of memory that is distinct for each user or process.
Thread-safe
------------------
Thread-safety is a programming concept applicable to multi-threaded programs. A piece of code is thread-safe if it is reentrant or protected from multiple simultaneous execution by some form of mutual exclusion.
Страницы: 1 вся ветка
Форум: "Основная";
Текущий архив: 2004.02.06;
Скачать: [xml.tar.bz2];
Память: 0.5 MB
Время: 0.093 c