TMS320c6678 и многоядерность, Как раскидать задачи на разные ядра ? Опции

[Digi]

Не могу понять, как в один *.out файл поместить програмные модули, которые должны работать в разных ядрах.
И вообще я еще не понял принцип работы программы в многоядерном процессоре. Я понял я так: К примеру Ядро 0 выполняет задачи передачи данных, обобщение результатов вычислений. Ядра 1-4 вычисляют принятые во внутреннюю память данные и укладывают туда же результаты. Связь между ядрами осуществялется через внутренюю память.
Это правильно или как то иначе ?

[Hoodwin]

Ну, еще бывают кольцевые очереди (FIFO), через которые можно сообщения слать из одного ядра в другое через общую память. Главная фича FIFO, в отличие от связанных списков списков и spinlock-ов, в том, что они гарантируют корректную работу очередей при асинхронном взаимодействии ядер, без спец. команд типа compare and exchange. Ну и операции с FIFO атомарные, O(1).

[AndrewN]

FIFO, в отличие от связанных списков

Ну-ну. FIFO и есть связанный список. Какие отличия???

FIFO [...] гарантируют корректную работу очередей при асинхронном взаимодействии ядер, без спец. команд

Ничего FIFO не гарантирует, синхронизацию доступа надо аппаратными средствами осуществлять, причем в 667х эти средства есть.

операции с FIFO атомарные, O(1)

Экие у вас странные представления о необходимых и достаточных условиях. Из О(1) вовсе не следует атомарность, этот термин для других целей используется.

Формально двусвязный список тоже можно считать очередью (FIFO)

Формально никакая это не очередь, а именно двусвязный список. Очереди вторая связь совершенна не нужна. В n-арном дереве тоже можно найти подграфы, которые можно очередями считать.

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

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

Не могу понять, как в один *.out файл поместить програмные модули, которые должны работать в разных ядрах.

Что бы долго не думать, я собираю несколько исполняемых файлов. В максимуме - восемь.

[jcxz]

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

Причём тут везение и какие индексы в очереди? Очереди у меня безиндексные - они там не нужны, это не массив.
И искалечить процессы (или процессоры) ничего не могут в принципе, если у вас правильно построены очереди и алгоритм работы с ними.
В очереди есть два указателя: один - позиция записи, другой - позиция чтения.
У каждой очереди есть пишущий процесс (процессор) и читающий процесс (процессор). У очереди может быть ТОЛЬКО ОДИН пишущий процесс (CPU) и ТОЛЬКО ОДИН читающий процесс (CPU).
В процессе записи модифицируется ТОЛЬКО указатель записи, указатель чтения при этом используется только как read-only.
В процессе чтения модифицируется ТОЛЬКО указатель чтения, указатель записи при этом используется только как read-only.
Таким образом - каждый из указателей модифицирует только свой процесс (CPU) и другой процесс (CPU) его использует только на чтение.
Такой алгоритм работы очередей позволяет не использовать критические секции (сериализацию доступа к ресурсу), что очень ценно для межъядерного взаимодействия.
Да, конечно, операция модификации (записи) указателя очереди должна быть атомарной, но это не проблема в любом CPU.

PS: А чтобы не "вляпываться в ситуации", надо продумывать алгоритм, а не рассчитывать на везение

[AndrewN]

Причём тут везение и какие индексы в очереди?

Везение при том, что алгоритм вы описали неубедительный. Первый оверран испортит ваш кольцевой буфер, а вы и не заметите.
Индексы (или указатели, различия малы) применяются в кольцевых буферах для указания начала и конца очереди.

Да, конечно, операция модификации (записи) указателя очереди должна быть атомарной, но это не проблема в любом CPU.

Это и есть синхронизация. Только кто же эту атомарность-то обеспечит? Какой механизм вы используете? В некоторых (далеко не во всех) ЦПУ есть аппаратные атомарные операции, а в остальных - это проблема...

атомарной операцией (то есть не зависящей от состояния структуры) является вставка и удаление

Еще раз - атомарная операция - это совершенно другое. И весь ваш способ работы с FIFO, если он явно не использует атомарные (в смысле истинного определения) операции - опасен и ошибочен.

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

Ещё раз - FIFO не способ синхронизации. FIFO - способ организации данных.

Больше того, не просто так появился аппаратный IPC контроллер. Он-то и осуществляет алгоритм межпроцессорной синхронизации.

2), 3) - всё без исключения ложь. Когда вляпаетесь, не говорите, что мол, наколдовал.

Вообще говоря, мне не хочется подменять собой учебники. В учебниках говорится про синхронизацию и буферизацию и чем они отличаются.

[jcxz]

Везение при том, что алгоритм вы описали неубедительный. Первый оверран испортит ваш кольцевой буфер, а вы и не заметите.
...
2), 3) - всё без исключения ложь. Когда вляпаетесь, не говорите, что мол, наколдовал.
Вообще говоря, мне не хочется подменять собой учебники. В учебниках говорится про синхронизацию и буферизацию и чем они отличаются.

Похоже Вы плохо представляете как правильно организовать FIFO, устойчивую к перекрывающимся вызовам из разных процессов (CPU) без критических секций.
И совершенно не поняли п.3 который написал Hoodwin. Перечитайте его ещё и ещё. Там всё достаточно описано.
Поймите простой принцип использования FIFO: один процесс ТОЛЬКО ПИШЕТ, другой - ТОЛЬКО ЧИТАЕТ.
Указатель записи модифицирует ТОЛЬКО пишущий процесс, указатель чтения - ТОЛЬКО читающий. Никаких других переменных (изменяющихся в ходе работы FIFO)
быть не должно. Размер свободного места и размер занятого места в FIFO должны вычисляться только из текущих значений указателей и полного размера FIFO
(который - const). После модификации указателей, полезно вставлять инструкции барьеров (типа DMB в Cortex-ах).
Если следовать этому принципу, то FIFO можно использовать для передачи сообщений между процессами (CPU) без критических секций.
И никаких проблем с переполнением там нет. Пишущий процесс всегда может проверить сколько осталось места в очереди и отреагировать на это.
Как тогда скажите произойдёт ваше неожиданное переполнение??? Ведь другой процесс НЕ МОЖЕТ туда писать.

Насчёт атомарности операций записи: если в данном CPU имеются ассемблерные команды записи соответствующей разрядности (и нет проблем с выравниванием),
то запись указателя (позиции, индекса и т.п.) будет атомарной. Если у вас указатели FIFO 32-битные, то на ядрах C667х и ARM9 (в OMAP) запись будет одной командой.
Советую смотреть в листинг-файлы компилятора и изучать ассемблер.

[AndrewN]

Если следовать этому принципу, то FIFO можно использовать для передачи сообщений между процессами (CPU) без критических секций.

Да, да. Вы мне честно скажите, на какой самолёт работаете? Я в него никогда в жизни не сяду, под страхом смертной казни. И вам лично не советую - я же не зверь