CreateThread && Strings

← →
DillerXX © (2006-08-23 00:11) [0]

Как сделать так, чтобы в функции вызванной CreateThread все переменные типа String работли нормально и не вываливались порой с ошибками доступа к памяти :(

← →
Ketmar © (2006-08-23 00:21) [1]

делать синхронизацию. например, критическими секциями. или не использовать переменные в нескольких потоках одновременно.

← →
DiamondShark © (2006-08-23 01:05) [2]

Либо создавать потоки функцией SysUtils.BeginThread, либо перед созданием потоков присвоить System.IsMultiThread := true

← →
DiamondShark © (2006-08-23 01:07) [3]

> SysUtils.BeginThread

System.BeginThread, разуммеется.

← →
Ketmar © (2006-08-23 01:30) [4]

> [2] DiamondShark © (23.08.06 01:05)
не, Дим, только это не поможет. например, та же concat() -- всё равно операция не атомарная. и если один из аргументов изменится в процесее... грустно будет.

← →
DiamondShark © (2006-08-23 11:08) [5]

> и если один из аргументов изменится в процесее

И? Они же copy-on-write.

Нее... Строки тут ни при чём. Строки потокобезопасны, обсуждали уже тут, с копанием в коде.
Дело в диспетчере памяти.

← →
Пусик © (2006-08-23 14:35) [6]

> Нее... Строки тут ни при чём. Строки потокобезопасны, обсуждали
> уже тут, с копанием в коде.

Бред.

← →
Пусик © (2006-08-23 14:36) [7]

прошу прощения за резкость, но в [5] - чушь.

← →
Ketmar © (2006-08-23 16:07) [8]

> [5] DiamondShark © (23.08.06 11:08)
Дим, вот это: s := "abc"; -- да, потокобезопасно. а вот это: s := sa+sb; -- нет. потому что, хотя изменения в sa и sb -- да, потокобезопасны, но сама операция "+" -- ни разу. смотри: берём длину и адрес sa, например. после чего sa радостно меняется с перераспределением памяти. и операция копирования копирует марсианский грунт.

← →
DiamondShark © (2006-08-23 16:15) [9]

> после чего sa радостно меняется

каким образом?

← →
Пусик © (2006-08-23 16:19) [10]

> DiamondShark © (23.08.06 11:08) [5]
> > и если один из аргументов изменится в процесееИ? Они же
> copy-on-write.Нее... Строки тут ни при чём. Строки потокобезопасны,
> обсуждали уже тут, с копанием в коде.

Можешь итоговый тезис-подтверждение своего высказывания из той ветки привести?

← →
Ketmar © (2006-08-23 16:33) [11]

> [9] DiamondShark © (23.08.06 16:15)
другим потоком. вот случилось у него в это время странное. да, перераспределение памяти строки и изменения полей -- атомарные. а "+" -- нет. что я и пытаюсь пояснить. и вот такие штуки могут породить "баги-привидения".

← →
DiamondShark © (2006-08-23 16:34) [12]

> Ketmar © (23.08.06 16:33) [11]

Конкретнее. Оператор языка, изменяющий строку.

← →
Сергей М. © (2006-08-23 16:42) [13]

> Пусик © (23.08.06 16:19) [10]

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

А автор облажался на незнании отличий между BeginThread и CreateThread в плане сериализации обращений к памяти со стороны BMM)

← →
Пусик © (2006-08-23 16:43) [14]

> Ketmar © (23.08.06 16:33) [11]
> > [9] DiamondShark © (23.08.06 16:15)другим потоком. вот
> случилось у него в это время странное. да, перераспределение
> памяти строки и изменения полей -- атомарные.

Даже операция s := s1 не атомарная.

← →
Пусик © (2006-08-23 16:45) [15]

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

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

← →
Ketmar © (2006-08-23 16:46) [16]

> [12] DiamondShark © (23.08.06 16:34)
а это абсолютно не важно. см, например, исходник _LStrCat.
CALL _LStrSetLength MOV EAX,ESI MOV ECX,[ESI-skew].StrRec.length
всё. приехали. тот же подход в самой _LStrSetLength и т.п. т.е. строки никак не защищены. никаких блокировок и подобного. вот это: s := s0+s1; генерирует просто вызов _LStrCat3, где тоже никаких защит.

← →
DiamondShark © (2006-08-23 16:47) [17]

> Если DiamondShark приведет тезисы в пользу атомарности операции
> присваивания

С большим удовольствием. Но только когда увижу цитату, где я бы нечто подобное утверждал.

← →
DiamondShark © (2006-08-23 16:50) [18]

> Ketmar © (23.08.06 16:46) [16]

Ну и как это вызовет ошибки доступа к памяти? При условии, конечно, что МП сериализован.

← →
Ketmar © (2006-08-23 16:56) [19]

> [18] DiamondShark © (23.08.06 16:50)
а так, что на вход Move передаётся адрес старого буфера строки. после чего строка благополучно переезжает в новое место. и тут начинается бедлам.

← →
Пусик © (2006-08-23 17:01) [20]

> DiamondShark © (23.08.06 11:08) [5]
> > и если один из аргументов изменится в процесееИ? Они же
> copy-on-write.Нее... Строки тут ни при чём. Строки потокобезопасны,
> обсуждали уже тут, с копанием в коде.Дело в диспетчере
> памяти.

"...строки потокобезопасны..." - это может быть толтько в случае атомарности операции.

"...Дело в диспетчере памяти..." - тоже хотелось бы подробнее.

← →
DiamondShark © (2006-08-23 17:12) [21]

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

Это заблуждение.

> "...Дело в диспетчере памяти..." - тоже хотелось бы подробнее.

см. GetMem.inc
поиск по IsMultiThread

← →
Пусик © (2006-08-23 17:34) [22]

> DiamondShark © (23.08.06 17:12) [21]
> > это может быть толтько в случае атомарности операции.Это
> заблуждение.

Где аргументы?

> см. GetMem.incпоиск по IsMultiThread

И что?

← →
guav © (2006-08-23 18:02) [23]

> DiamondShark ©

Обсжудались ли WideString строки ? потокобезопасны ли они ?

← →
Суслик © (2006-08-23 18:05) [24]

Насколько я помню обсуждение, приведенное Дмитрием в качестве аргумента (я тогда тоже изрядно покопался в реализации строк), то вывод был такой: строки потокобезопасны с точки зрения получения неожиданного AV, но естественно не потокобезопасны с точки зрения логики работы программы. Т.е. операции над строками есно не атомарные, но результат хоть какой-то от операции получен быдет (может быть не в полне ожидаемый) но без AV.
Я тогда сам изрядно удивился этому факту.

← →
Ketmar © (2006-08-23 18:06) [25]

> [23] guav © (23.08.06 18:02)
та же фигня, что и с Ansi, только счётчика нет. %-)

← →
Ketmar © (2006-08-23 18:09) [26]

> [24] Суслик © (23.08.06 18:05)
ну ведь я только что генофонд смотрел. нет там защиты вокруг Move. нет, и всё. поэтому AV вполне может быть. другое дело, что не всегда, и даже не очень часто. %-)

← →
Суслик © (2006-08-23 18:09) [27]

ты что конкретно имеешь в виду? какую функцию?

я смотрю на _LStrCat3 = сложение двух ansiстрок

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

> Пусик © (23.08.06 17:34) [22]

Если тебя интересует именно разобраться -- читай system.pas, внимательно. Вспомни, что строки -- объекты со счётчиком ссылок, обрати внимание, что операции модификации "по месту" производятся только над уникальными (refcount=1) строками, обрати внимание, что подсчёт ссылок сериализован.

А если тебя интересует побыковать, то иди нафиг.

> дошло до вызова диспетчера памяти, который её и переместил

Неуникальную строку не переместит.

а если она уникальная, то с ней по-определению только один трид работает.

> а если она уникальная, то с ней по-определению только один
> трид работает.

а если это глобальная переменная?

Тогда балайка.

> DiamondShark © (23.08.06 18:48) [35]
> Тогда балайка.

Даже операции с Integer не потокобезопасны. Что же говорить про строки.

if s1=s2 then - потокобезопасная операция?

s1 := s2, где s1 - глобальная, потокобезопасная операция?

> А если тебя интересует побыковать, то иди нафиг.

Сам дурак.

> Суслик © (23.08.06 18:05) [24]
> Насколько я помню обсуждение, приведенное Дмитрием в качестве
> аргумента (я тогда тоже изрядно покопался в реализации строк),
> то вывод был такой: строки потокобезопасны с точки зрения
> получения неожиданного AV, но естественно не потокобезопасны
> с точки зрения логики работы программы. Т.е. операции над
> строками есно не атомарные, но результат хоть какой-то от
> операции получен быдет (может быть не в полне ожидаемый)
> но без AV.Я тогда сам изрядно удивился этому факту.

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

> Суслик © (23.08.06 19:19) [38]
> > 37] Пусик © (23.08.06 19:11)ты исходный вопрос автора
> то видел?

Видела.
А ты знаешь логику работы со строками у автора?
Именно потому, что автор получает непредсказуемый результат, и достигается AV.

CreateThread &amp;&amp; Strings Найти похожие ветки

CreateThread && Strings Найти похожие ветки