Потоки. Нужна ли синхронизация?

← →
oxffff © (2008-06-19 19:51) [120]

> Вот же блин - достал пиво из холодильника, а оно вспенилось.
> Нет в жизни счастья.

А я молоко пью оно полезней и не пенится. :)
Присоединяйтесь.

← →
Игорь Шевченко © (2008-06-19 19:54) [121]

oxffff © (19.06.08 19:51) [120]

Не, молоко после тяжелого жаркого дня не спасает.

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

← →
oxffff © (2008-06-19 20:19) [122]

> Игорь Шевченко © (19.06.08 19:54) [121]

Я честно говоря не читал эту статью.
Если возникнет необходимость, то я Memory Coherency and Protocol в документации на процессор. Например в AMD это MOESI.
И документацию у меня тоже имеется. :)

← →
oxffff © (2008-06-19 20:22) [123]

> Я честно говоря не читал эту статью.

У меня сейчас голова думает "Надо пойти профиля прикрутить на потолок".

← →
Sapersky (2008-06-19 20:25) [124]

Общий кэш второго уровня означает, что данные, прочитанные первым ядром в кэш L2, автоматически должны быть "видны" второму ядру, что позволяет нам рассчитывать на получение очень хороших результатов. Давайте на них посмотрим.

Давайте, посмотрим:
"Отсюда следует поразительный вывод: доступ к модифицированным данным, расположенным в кэше первого уровня другого ядра, происходит по тем же самым принципам, что и доступ к данным в кэшах ядер процессоров Athlon 64 X2 и Pentium D. То есть последняя действительная копия данных сначала отправляется на запись в оперативную память через системную шину, а затем передаётся обратно во второе ядро."

Т.е. в общем обмен между ядрами у CoreDuo получше, чем у других, но в некоторых случаях всё равно идёт через память.
И, собственно, программы ведь пишутся не только для CoreDuo, но и для этих "других" тоже, нет?

← →
oxffff © (2008-06-19 20:35) [125]

> Sapersky (19.06.08 20:25) [124]
> Общий кэш второго уровня означает, что данные, прочитанные
> первым ядром в кэш L2, автоматически должны быть "видны"
> второму ядру, что позволяет нам рассчитывать на получение
> очень хороших результатов. Давайте на них посмотрим.
>
> Давайте, посмотрим:
> "Отсюда следует поразительный вывод: доступ к модифицированным
> данным, расположенным в кэше первого уровня другого ядра,
> происходит по тем же самым принципам, что и доступ к данным
> в кэшах ядер процессоров Athlon 64 X2 и Pentium D. То есть
> последняя действительная копия данных сначала отправляется
> на запись в оперативную память через системную шину, а затем
> передаётся обратно во второе ядро."

И как это противоречит моим словам?
Я не вижу в твоем посте упонимания о различном представлении памяти в разных ядрах.
А речь шла об этом.

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

Я частенько появляюсь в конференции "Процессоры" на Ixbt, но в основном в качестве зрителя. Не хочу выглядить профаном.
Там какие изречения не любят. Уж больно дядьки серьезные.
Получше это как?

> И, собственно, программы ведь пишутся не только для CoreDuo,
> но и для этих "других" тоже, нет?

Да, и что дальше? :)

← →
Sapersky (2008-06-19 20:50) [126]

Я вообще-то не собирался обсуждать приведённую статью. Меня больше интересует, на каком основании сделан вывод, что Synchronization and Multiprocessor Issues не распространяются на многоядерные системы.
Статья приведена только для того, чтобы показать, что обмен между ядрами в двухядерниках часто идёт через системную память, и, по моему разумению, они в этом смысле не отличаются принципиально от двухпроцессорных систем.

← →
Sapersky (2008-06-20 11:18) [127]

Если возникнет необходимость, то я Memory Coherency and Protocol в документации на процессор. Например в AMD это MOESI.

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

← →
oxffff © (2008-06-20 17:22) [128]

> Sapersky (20.06.08 11:18) [127]

Читай внимательно oxffff © (19.06.08 19:46) [118].
Автоматически тебе ничего не говорит?

← →
oxffff © (2008-06-20 17:37) [129]

>Sapersky (20.06.08 11:18) [127]

http://www.oszone.ru/3503/Dual

Каждое из ядер Athlon 64 X2 обладает собственным набором исполнительных устройств и выделенной кэш-памятью второго уровня; контроллер памяти и контроллер шины HyperTransport общие. А вот взаимодействие каждого ядра с разделяемыми ресурсами происходит посредством специального коммутатора (Crossbar Switch) и интерфейса системных запросов (System Request Interface), в котором формируется очередь системных запросов (System Request Queue). И, что самое главное, на этом же уровне организовано и взаимодействие ядер, благодаря чему вопросы когерентности кэшей решаются без дополнительной нагрузки на системную шину и шину памяти.

← →
Sapersky (2008-06-20 19:29) [130]

Нашёл пресловутую страницу в документации (Multiprocessor Memory Access Ordering).
Правда, не вполне понятно, относится ли AMD"шное "Multiprocessor" только к многоядерным или к многопроцессорным системам тоже. Intel в соответствующем документе уточняет: "The term processor refers to a logical processor, which may be one processing component of a hyperthreaded physical processor or of a multi-core physical package.", т.е. вроде как только про многоядерники.

← →
oxffff © (2008-06-20 19:33) [131]

> Sapersky (20.06.08 19:29) [130]
> Нашёл пресловутую страницу в документации (Multiprocessor
> Memory Access Ordering).

И что в этой странице пишется?

← →
Sapersky (2008-06-20 19:48) [132]

Loads do not pass previous loads (loads are not re-ordered). Stores do not pass previous stores (stores are not re-ordered).

In the examples below all memory values are initialized to zero.

Processor 0 Processor 1
Store A ← 1 Load B
Store B ← 1 Load A

Load A cannot read 0 when Load B reads 1.

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

> Sapersky (20.06.08 19:48) [132]

А можно пример полностью или № документ или ссылка на документ со страницей. А то выдран из непонятного контекста.

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

← →
Sapersky (2008-06-21 09:12) [135]

А можно пример полностью или № документ или ссылка на документ со страницей. А то выдран из непонятного контекста.

AMD64 Architecture Programmer’s Manual Volume 2: System Programming
Memory System \ Multiprocessor Memory Access Ordering (стр. 164)
У Intel:
Intel® 64 Architecture Memory Ordering

Эта...господа спорящие,

Да никто уж не спорит (поначалу было немного - дык, дурной пример заразителен :)).
Лично я пытаюсь понять, к чему относится статья микрософта (где-то ранее была ссылка), если Intel/AMD в своих мануалах её фактически опровергают. Может, к каким-нибудь Alpha или PowerPC - тем лучше, конечно, но хотелось бы однозначно убедиться.

> AMD64 Architecture Programmer’s Manual Volume 2: System
> Programming

У меня такой есть.
Просмотрел весь 7 раздел. Но примера не нашел?
У меня
Publication No. Revision Date
24593 3.11 December 2005

А какая страница? :)

Меня смущает

>Loads do not pass previous loads (loads are not re-ordered). Stores do not >pass previous stores (stores are not re-ordered).

1. Implementations of the AMD64 architecture retire instructions
in program order, but implementations can execute instructions
in any order. ....
However, because implementations can execute
instructions out of order and speculatively, the sequence of memory accesses
can also be out of program order (weakly ordered).

For cacheable memory types, the following rules govern read
ordering:
Out-of-order reads are allowed. Out-of-order reads can occur
as a result of out-of-order instruction execution or
speculative execution. The processor can read memory outof-
order to allow out-of-order execution to proceed.

Reads can be reordered ahead of writes.
A read cannot be reordered ahead of a prior write if the read
is from the same location as the prior write.

Generally, out-of-order writes are not allowed. Write
instructions executed out of order cannot commit (write)
their result to memory until all previous instructions have
completed in program order. The processor can, however,
hold the result of an out-of-order write instruction in a
private buffer (not visible to software) until that result can
be committed to memory.

Write buffering is allowed. When a write instruction
completes and commits its result, that result can be buffered
before actually writing the result into a memory location in
program order. Although the write buffer itself is not
directly accessible by software, the results in the buffer are
accessible during memory accesses to the locations that are
buffered.

Write combining is allowed. In some situations software can
relax the write-ordering rules and allow several writes to be
combined into fewer writes to memory. When writecombining
is used, it is possible for writes to other memory
types to proceed ahead of (out-of-order) memory-combining
writes, unless the writes are to the same address. Writecombining
should be used only when the order of writes
does not affect program order

When the order of memory accesses must be strictly enforced,
software can use read/write barrier instructions to force reads
and writes to proceed in program order.

Однако

In some cases, data can be modified in a manner that is
impossible for the memory-coherency protocol to handle due to
the effects of instruction prefetching.

← →
Sapersky (2008-06-22 04:11) [137]

У меня поновее:
Publication No. Revision Date
24593 3.14 September 2007
стр. 164
Возможно, в 2005 г. и ранее всё так и было, как описано в старой
документации. Многопроцессорные системы имели известные проблемы, но в силу малой распространённости AMD предпочитал уповать на продвинутость пишуших под них программистов. Потом появились куда более популярные двухядерники, и AMD пришлось заткнуть наиболее опасные "дырки", чтобы не портить жизнь рядовым кодерам.
Версия всем хороша, кроме одного момента: первый Athlon X2 появился в апреле 2005-го. Н-ну, может быть, в AMD очень медленно пишут обновления к документации...

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

То есть так, как я и озвучивал выше. :)
Но с твоим доказательством. Спасибо.

Потоки. Нужна ли синхронизация? Найти похожие ветки