Можно ли обратиться из двух разных потоков к полям другого класса?

Добрый день! Имеется ПОТОК1 и ПОТОК2 (TThread). Есть Класс1 отнасследованный от TObject.
Суть в том что в Потоке1 происходит заполнение Поля Класс1.msg1. Далее Поток1 делает синхронизацию Вызывает метод Класс1.Sync в данном методе по мере необходимости происходит копирование Класс1.msg2 := Класс1.msg1;
ПОТОК2 Обрабатывает то что находиться Класс1.msg2, но это делает тогда когда точно не происходит Копирования msg1 в msg2. Т.е. одновременного обращения записи/чтения к одному и тому же полю из разных потоков класса1 отсутствует. Но мне не понятно, могу ли я вообще обращаться к одному классу из разных потоков? Это может привести к какой-то ошибке? Или все таки нельзя обращаться к одному классу из двух потоков, даже если поля разные?.

0

Сообщение от Иван Ежик Менеджер памяти может переписать в любое время адрес по этому указателю (если ему понадобится перенести объект фактически в непрерывный участок памяти)?

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

0

Сообщение от AzAtom Адрес объекта сам по себе не меняется

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

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

0

Сообщение от Иван Ежик Экземпляр имеющий внутри себя динамический массив, сменит только указатель на "конкретное измерение" если ему не будет хватать непрерывной памяти?

Тут да, передаётся адрес данных, который может измениться при изменении размера массива.

Но если сделать
то будет передан адрес переменной a: TIntArray; который уже содержит адрес данных. И даже если поменять размер массива, то доступ к данным останется. Ну и обращаться к массиву нужно через синхронизацию, конечно, а то не исключена смена адреса массива во время обращения к нему потока. Тогда хорошо, если выскочит AV.

1

верно
продолжая аналогию с адресами, надо иметь не сам адрес, а место, где этот адрес будет лежать, в случае когда путешественник часто переезжает, но адрес своего текущего места хранит где-то и уже вот это место точно не меняется

и еще раз - менеджер не может ничего поменять сам
только по команде

0

Сообщение от krapotkin и еще раз - менеджер не может ничего поменять сам только по команде

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

Добавлено через 3 минуты

Сообщение от Иван Ежик тут уже я не берусь судить

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

0

Сообщение от Иван Ежик Но стоит вызвать ф-цию канваса, и хендл уже invalid

Дельфийский Canvas это довольно таки "вещь в себе". Может и пересоздаёт битмап при некоторых операциях, не знаю. По крайней мере, при работе с ним нельзя надеяться, что какой-то хэндл будет вечным.

Сообщение от Иван Ежик менджер памяти перевыделил её, а мог бы подставить по прежнему указателю или обновить его.

Не мог бы. Менеджер памяти просто выделяет кусок памяти и возвращает её адрес, а обновлять эти адреса должна уже программа сама в своих же переменных.

0

Сообщение от Иван Ежик мы берём хендл битмапа

не путаем теплое с мягким
handle - это ID системного(!) ресурса, которым оперирует ОС
Поэтому для операций, где важна консистентность, мы обязаны его ЗАПРОСИТЬ(ЗАЛОЧИТЬ)! и ОТПУСТИТЬ!
В данном случае МП по отношению к ОС ведет себя как программа по отношению к МП.
При этом ОС залоченную память тоже не сменит. И залоченный хендл не поменяет.

МП берет большие куски памяти у ОС, получая на них хендлы, и потом отдает. Медленно.
А нам выдает по требованию. Быстро.
Вот все для чего он нам нужен.
Но сам ничего поменять не может

1

Сообщение от krapotkin Но сам ничего поменять не может

Но если попробовать пример с "доступом к памяти битмапа напрямую, а потом нарисовать на нём средствами канваса", то при следующем доступе напрямую будет AV...Кто-то поменял его расположение в памяти, хотя размер битмапа не поменялся.

Сообщение от krapotkin не путаем теплое с мягким

Да, я ошибся в формулировке, имел в виду прямой доступ к памяти картинки

Добавлено через 4 минуты

Сообщение от AzAtom Ну и обращаться к массиву нужно через синхронизацию, конечно, а то не исключена смена адреса массива во время обращения к нему потока.

Так а с экземплярами класса это как работает? Я к тому что рекомендуют синхронизировать доступ к полям но не к самой переменной экземпляра(которая являясь ссылочным типом по сути и есть указатель, но который не может быть изменён с помощью арифметики указателей)

Добавлено через 1 минуту

Сообщение от AzAtom По крайней мере, при работе с ним нельзя надеяться, что какой-то хэндл будет вечным.

Я ошибся, не хендл имел в виду а доступ к памяти картинки...

0

Память картинки, если эта картинка - системный ресурс (а в VCL это именно так) - закрыта
Поэтому берем хендл и далее по списку...
В частности, потому что все форматы и JPEG и PNG ложатся в единый системный bmp, с которым GDI только и умеет работать.

В FMX уже ввели TBitmapSurface - там просто голые данные, никто их не заберет.

Сообщение от Иван Ежик рекомендуют синхронизировать доступ к полям

Рекомендации не бывают исчерпывающими.
Нужен контекст
У каких-то объектов поля все время текут
Например List будет все время изменять свой внутренний массив, т.е. ссылка на него будет меняться
поэтому надо лочить сам List, брать массив, делать что-то , отпускать List.

Со строкой, насколько я помню, еще интереснее.
Объект может поменять поле-строку, в этом случае ссылка на нее изменится, но предыдущая ссылка будет содержать старую строку. Без AV.

0

Сообщение от Иван Ежик Я к тому что рекомендуют синхронизировать доступ к полям но не к самой переменной экземпляра

Переменная объекта и называется полем. Не пойму, в чём проблема. Пока существует экземпляр объекта, его поля тоже на месте.

Сообщение от Иван Ежик имел в виду а доступ к памяти картинки

У меня с этим проблем не было. Можно пример с таким эффектом?

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

0

Сообщение от krapotkin Память картинки, если эта картинка - системный ресурс (а в VCL это именно так) - закрыта Поэтому берем хендл и далее по списку...

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

Сообщение от AzAtom У меня с этим проблем не было. Можно пример с таким эффектом?

Я думаю несколько лет назад это упоминал тут на форуме.
Если коротко то нужно было нарисовать рамку на распознанном на картинке объекте, я долго не мог понять почему появлялись AV...
А сделано было так

begin
Читаем память картинки напрямую, распознаём;
Рисуем рамку или сдвигаем окно если не удалось.
Проверяем некое условие нужно ли повторить и так по кругу.
end

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

Сообщение от AzAtom Переменная объекта и называется полем. Не пойму, в чём проблема. Пока существует экземпляр объекта, его поля тоже на месте.

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

0

Сообщение от Иван Ежик Все 10 условных параллельных потоков могут?! одновременно обратится к указателю на экземпляр класса

Могут, если программист гарантирует, что переменная/поле, содержащая адрес объекта будет жить во время работы этих потоков.

Сообщение от Иван Ежик и за вчера так никто и не ответил, как будто специально делая вид, что не замечают.

А это что?

Сообщение от AzAtom А как поток узнаёт адрес объекта? Обычно, он же передаётся заранее, при создании объекта потока. Вот и будет поток хранить адрес объекта в своей области памяти.

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

Хотя, не вижу препятствий для чтения всеми потоками и из одной переменной, при условии, что эта переменная будет жива всё время работы потоков. Читайте на здоровье, тем более, если эта переменная считывается за одно чтение, то вообще нет проблем.

А вот с тем же динамическим массивом уже нужны меры, а то, пока один поток читает данные, другой поток вздумает изменить размер массива и он "переедет" по другому адресу памяти, тогда, первый поток может получить AV.

1

Сообщение от AzAtom А это что?

Ну там не ответ про 10 потоков ) и если сделать именно так как указано (назначить адрес при создании потока) то гарантированно два потока не смогут одновременно обратится к адресу экземпляра, ведь создание занимает время, поэтому я и не воспринял как ответ про одновременный доступ.

Спасибо.

0