| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Потокобезопасные типы хранения данных ? [D5, D7, Win95/98, WinXP]
Cheburek © (2004-11-09 20:14:00)Хай. Не поможете ?
Требуется тип данных, потокобезопасный.
Отвечают ли таким требованиям Variant ? Динамические массивы ? Представители класса TStringList ?
Желательно что бы был быстрый поиск, быстрая вставка и удаление, возможность хранить инфу в удобном виде.
Меня устраивает и TStringList, но вроде бы он не потокобезопасен, а Synhronize использовать не охота.
Помогите советом...
Заранее всем спасибо.
Defunct (2004-11-10 07:35:00) [21]> А вообще давно мечтал на практике посмотреть. Пожалуй, куплю двухпроцессорную мать с получки...
PS: это хорошее вложение.
> Может, в эти отличия входит и защитный механизм от коллизий?
Все гораздо проще, как отметил
Verg © (10.11.04 00:06) [9]
Между этими циклами возможен захват шины в пользу другого процессора
применяется механизм захвата системной магистрали, т.е. в конкретный момент времени с памятью может работать только одно устройство (либо процессор, либо КПДП).
> раз вероятность совпадения высока, то это должно просто бросаться в глаза, тем, кто всю эту кашу заварил...
Вопрос разрешения конфликтов по доступу к общему ресурсу является если не самым важным, то уж одним из наиболее важных в огранизации параллельных систем. Над ним и работают целые институты. Вот к примеру SUN Microsystems уже добилась того, что в SMP системе может быть сотни процессоров, а всего лишь пару лет назад число процессоров ограничивалось десятками.
Defunct (2004-11-10 07:11:00) [22]KilkennyCat © (10.11.04 00:29) [10]
> но насколько я слышал, разработка программ под более чем один процессор, равно как и ОС, поддерживающие мультипроцессорность, несколько отличается от стандартной схемы.
Когда вы пишите многопоточную программу на Delphi (хотя бы 2 потока), такая программа уже является программой, способной выполняться в SMP (Symmetric MultiProcessing) системе на двух процессорах (SMP - система с общей памятью).
Отличие в программировании будет только для не симметрических систем с разделяемой памятью (MPP - Massively Parallel System, NUMA - Non Uniform Memory Access) и расределенных систем (кластерная организация).
> либо существуют механизмы, препятствующие писать в одну ячейку памяти разным процессорам?
Обязательно существуют, исключения составляют системы с многопортовой памятью, но и там действует правило - кто последний тот и прав, а при одновременной записи конфликт разрешается контроллером памяти в пользу порта с меньшим номером.
KilkennyCat (2004-11-10 00:30:00) [23]Кроме того, аппаратная реализация может запретить подобное.
KilkennyCat (2004-11-10 00:29:00) [24]Прошу прощения, ежели слишком ламерно выскажусь, но насколько я слышал, разработка программ под более чем один процессор, равно как и ОС, поддерживающие мультипроцессорность, несколько отличается от стандартной схемы. Может, в эти отличия входит и защитный механизм от коллизий? раз вероятность совпадения высока, то это должно просто бросаться в глаза, тем, кто всю эту кашу заварил...
А вообще давно мечтал на практике посмотреть. Пожалуй, куплю двухпроцессорную мать с получки...
Verg (2004-11-10 00:06:00) [25]Если адрес 4-х байтника не выровнен по границе 4-х байтов, то операция записи или чтения может перестать быть атомарной?
Грубо говоря, арбитру шины может понадобится более одного цикла шины для записи этой ячейки. Между этими циклами возможен захват шины в пользу другого процессора, т.о. поток выполняющийся на нем может прочитать некое "промежуточное" значение этой ячейки.
Вот и выплывают InterLockedExchange и т.п., которые для многопроцессорного ядра выполняются с префиксом блокировки шины.
Вообще невыровненные поля структур - это я считаю недостатком проекта. Поле структуры должно иметь смещение от начала структуры кратное размеру этого поля.
Anatoly Podgoretsky (2004-11-09 23:47:00) [26]panov © (09.11.04 23:36) [6]
Насчет потоков все нормально, а вот насчет процессоров не могу сказать, не знаю какие сейчас механизмы доступа к памяти, но не думаю, что это возможно одновременно даже для ДМА, это был бы полнейних крах системы, так что кто последний тот и прав и это относится и к одному процессору точно также.
KilkennyCat © (09.11.04 23:40) [7]
Высокая
KilkennyCat (2004-11-09 23:40:00) [27]
> panov © (09.11.04 23:36) [6]
а вероятность, что они будут одновременно, высока?
panov (2004-11-09 23:36:00) [28]>Anatoly Podgoretsky © (09.11.04 23:18) [5]
Что будет, если 2 потока, выполняющихся на разных процессорах, одновременно будут записывать данные таким образом:
Поток 1:
A := $80;
Поток 2:
A := $40;
Определено ли будет значение переменной после выполнения такой операции, либо существуют механизмы, препятствующие писать в одну ячейку памяти разным процессорам?
Anatoly Podgoretsky (2004-11-09 23:18:00) [29]Ну не знаю, убежду или нет, если операция атомарная, то она потокобезопасна. Видимо ты имеешь в виду, последовательность, чтение, модификация, запись, я же рассматриваю их по отдельности. Вот пример
A := 5; (1, 2, 4, на всякий случай выровненые на границу кеша)
A := B уже не безопасно.
A := A + 5 это уже вообще один известный пушной зверек.
panov (2004-11-09 23:10:00) [30]>Anatoly Podgoretsky © (09.11.04 20:55) [2]
Буду рад, если убедите в обратном раз и навсегда.
panov (2004-11-09 23:09:00) [31]>Anatoly Podgoretsky © (09.11.04 20:55) [2]
Даже 4-х байтные типы не являются потокобезопасными при использовании на многопроцессорных компьютерах, несмотря на то, что Borland(почему - мне непонятно до сих пор), использует тип Boolean без защиты кода критической секцией.
Anatoly Podgoretsky (2004-11-09 20:55:00) [32]Не отвечает, а отвечают только типы не большие чем 4 байта, которые могут быть прочитаны/записаны одной процессорной командой. Все остальные требуют синхронизации (то бишь блокировки на операцию).
Cheburek (2004-11-09 20:46:00) [33]Удалено модератором
| |
Страницы: 