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]

> В частности реентерабельностью должны обладать рекурсивные
> процедуры.

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

>Это неубедительно и это спорно. Это может быть так же
>нереентерабельно как и непотокобезопасно.
Все переменные храним в стеке. Причины нереентерабельности назовите.

>Понятие потоко-безопасного кода порождено собственно методом
>реализации потоков.
А если система многопроцессорная и потоки крутятся на разных процессорах? :o)

>А это вообще из другой оперы.
Из той же. Рекурсия - частное проявление реентерабельности.

> vuk © (24.01.04 17:16) [12]
> >Так разъясните уж в чем же принципиальная разница.
> Пример. В процедуре создаем и используем именованный FileMapping.
> Реентерабельно? Да, не вопрос. Потокобезопасно? Нет.

Тут про способ хранения/использования переменных ни слова....

> Все переменные храним в стеке. Причины нереентерабельности
> назовите.

Так, ну "рояль в кустах" или "туз в рукаве" или все же зачем-то
именованный FileMaping?

Verg (C)
> Простейшее правило - не использовать или использвать по
> правилам ОС (например, крит. секции) глобальные переменные.

> А если система многопроцессорная и потоки крутятся на разных
> процессорах? :o)

Да хоть так. Сути дела это не меняет.

Не, серъезно, подумайте об этом еще раз.

> Из той же. Рекурсия - частное проявление реентерабельности.

Значит мы с вами используем один термин (слово) для обозначения разных по сущности свойств кода.

>Тут про способ хранения/использования переменных ни слова....
Каюсь, забыл упомянуть об этом. Думал, что это очевидно.

>Так, ну "рояль в кустах" или "туз в рукаве" или все же зачем-то
>именованный FileMaping?
Например, для передачи данных между процессами.
Так что с причинами нереентерабельности?

>Да хоть так. Сути дела это не меняет.
Правда? То есть два потока на одном процессоре - это то же самое, что и два потока на двух процессорах? Или все-таки это уже не только разделение времени?

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.

Thread-safe код - это как? Найти похожие ветки