Jump to content

    
Sign in to follow this  
Serg_el

Атомарность чтения

Recommended Posts

И еще: кто-нить пользуется SVC? Может, лучше через SVC, раз "лишние" прерывания KnightIgor не напрягают?

Я пользуюсь :)

 

Да элементарно. Представим себе модем. Скорость rs232 115200, скорость по линии 33600. И ваш fifo по определению переполняется. Дабы этого не происходило, вам надо при заполнении фифо на 90% управлять потоком. То есть высылать XOFF либо снимать RTS. А при освобождении буфера необходимо опять разрешать подгрузку. В целом так будет происходить в любом случае, когда скорость обработки информации меньше чем скорость заполнения буфера.

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

Фловконтроль для согласования скоростей каналов и программный фифо - несколько разные вещи.

Да, управлять потоком можно от уровня заполненности программного FIFO.

Так вот - для вычисления уровня заполненности FIFO критическая секция совсем не нужна :)

На чтение обе стороны могут использовать оба указателя FIFO. На запись - каждая сторона только свой указатель.

 

Это видимо имелось в виду программное прерывание. Правильнее его называть SWI.

Может и правильнее, но в документации Cortex оно называется SVC (SuperVisor Call). :)

Share this post


Link to post
Share on other sites
Так вот - для вычисления уровня заполненности FIFO критическая секция совсем не нужна :)

Я написал "в общем случае". :rolleyes:

 

Share this post


Link to post
Share on other sites
Проще использовать мютексы и не городить сложных систем с критическими секциями и платформозависимой атомарностью. Не разделяю любви с неблокирующим алгоритмам - их очень трудно поддерживать и очень легко сломать.

Интересно - как вы с помощью мьютексов и прочих блокирующих методов синхронизируете работу фоновой задачи с ISR-ами?

Научите!

 

К тому-же - реализация мьютексов в ОС имхо всегда основывается внутри на критических секциях и/или атомарном доступе.

Share this post


Link to post
Share on other sites
Интересно - как вы с помощью мьютексов и прочих блокирующих методов синхронизируете работу фоновой задачи с ISR-ами?

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

 

реализация мьютексов в ОС имхо всегда основывается внутри на критических секциях и/или атомарном доступе.

Кто же спорит. Но мы этого не видим и туда без необходимости не лезем.

Share this post


Link to post
Share on other sites
Я пользуюсь :)

На чистом C или с ASM-вставками?

В Keil или GCC?

 

Может и правильнее, но в документации Cortex оно называется SVC (SuperVisor Call). :)

Насколько я понял, разработчики Cortex-M изменили название инструкции (сохранив числовое значение) при переходе с ARM7,

чтобы программист, который портирует код уделил внимание особенностям новой системы исключений.

Share this post


Link to post
Share on other sites
Поллинг и фифо решают 90% задач связанных с прерываниями. Если надо из ISR сигнализировать приложению, то можно в задаче захватывать семафор, а в прерывании отпускать. Это позволит заблокировать задачу до прихода прерывания.

Фифо - это не блокирующий метод.

И что толку от сигнализации если нужно эксклюзивное чтение-модификация-запись некоей области памяти в ISR и фоновой задаче (критическая секция)?

Хорошо если можно в ISR тупо писать/читать в фифо. А если нужна работа с более сложной структорой данных в памяти?

Или то же самое фифо, но несколько писателей или несколько читателей? Как вы тут без критической секции обойдётесь?

Share this post


Link to post
Share on other sites

Тут достаточно не критической секции, а запрета конкретного источника прерывания перед установкой семафора. При работе с ISR так или иначе запрещать прерывания придётся. Но но уровне операционки можно написать тонны софта ни разу не встретившись с прерыванием. В линуксе скажем они где-то глубоко запрятаны. В таком случае городить всякие lock-free и критические секции нет никакой нужды до тех пор, пока реально не понадобится улучшить производительность.

Share this post


Link to post
Share on other sites
На чистом C или с ASM-вставками?

В Keil или GCC?

В IAR. Вызовы - на си, обработчик SVC - на асме.

Вот так декларирую:

#define SVCF_trap0       0
#define SVCF_trap1       1
#define SVCF_trap2       2
#define SVCF_trap3       3
#define SVCF_trapMax     SVCF_trap3
#define SVCF_AppRestart  (SVCF_trapMax+1)
#pragma swi_number=SVCF_trap0
__swi void trap(u32);
#pragma swi_number=SVCF_trap1
__swi void trap(u32, u32);
#pragma swi_number=SVCF_trap2
__swi void trap(u32, u32, u32);
#pragma swi_number=SVCF_trap3
__swi void trap(u32, u32, u32, u32);
#pragma swi_number=SVCF_AppRestart
__swi void AppRestart();

Как видите - SVC использую для вызова обработчика критических ошибок. Вызовов таких в коде - тьма-тьмущая (одних только ASSERT-ов...).

А с использованием SVC вызов получается очень компактным.

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

Share this post


Link to post
Share on other sites
Поллинг и фифо решают 90% задач связанных с прерываниями. Если надо из ISR сигнализировать приложению, то можно в задаче захватывать семафор, а в прерывании отпускать. Это позволит заблокировать задачу до прихода прерывания.

 

 

Кто же спорит. Но мы этого не видим и туда без необходимости не лезем.

 

А если существует более чем один источник часто повторяющихся прерываний, то эти ваши "невидимые" семафоры в прерываниях уронят всю систему. И в сервисах осей как раз стопроцентно используются критические секции. Уже два раза напоролся на такое - сейчас принципиально стараюсь в прерываниях не юзать осевые сервисы.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this