[완료] Priority가 다른 task간의 동기화 문제.

우선 reader와 writer 관계와 같이 priority의 개념이 그다지 필요하지 않거나 중요도의 차이가 크게 나지 않는 task 관계라면, 서로 동등한 priority를 주고 RR을 하게 하는게 프로그래밍 모델을 간단하게 하는 방법입니다.
동일 priority에서 RR을 지원하지 않고 FIFO만 지원하는 kernel이라면 yield하게 해서 RR과 같은 효과를 줄수도 있습니다.
그다지 중요도가 높지 않은 task들은 위와 같이 구성하고 중요도가 높은 task만 보다 높은 priority를 주면 real-time을 해치지도 않기 때문에 나쁘지 않은 방법입니다.

==== 인용 ================================
그게 아니라 priority가 낮은 task와, 매우 높은 ISR이 서로 경쟁할 경우 참 난감할것 같더라구요. 예를 들어...task가 lock을 소유하고 있는데 ISR이 치고 들어와서 lock을 acquire하려고 한다면...당연히 dead lock 상태로 빠져들것입니다.
==========================================

시스템 설계의 원칙중 하나는 어떠한 경우라도 ISR과 task가 lock을 가지고 경쟁하게 해서는 안된다는 것입니다. ISR 내에서는 wait가 발생할수 있는 어떠한 lock primitive도 사용할수 없습니다.
lock이 이미 locked 되었다면 필연적으로 task를 wait하게되는데 ISR에서는 wait할 task 주체가 개념적으로 없기 때문에 시스템이 deadlock 빠져버리거나 혹은 아예 뻗어버립니다.

ISR과 경쟁할 자원을 이미 획득하고 있던 task에서 IRQ가 발생하면 deadlock이 발생하고, 다른 task가 자원을 획득하고 있었는데 ISR과 경쟁하지 않는 task에서 IRQ가 발생하면 나중에 scheduling시 뻗어버립니다.
이는 stack과 관계된 문제로써 대부분의 RTOS들은 별도의 IRQ stack을 두고 IRQ nesting이 발생할때 context를 IRQ stack에 save하는데 wait는 task의 stack에 context를 save하는것을 전재하고 설계되어 있는데 IRQ stack에 task의 context를 save 함으로써 발생하는 문제입니다.

결국 이러한 원인 역시 wait할 task의 주체가 ISR에서는 개념적으로 존재하지 않기 때문에 발생하는 현상중에 하나입니다.

때문에 임베디드 상황에서는 절대 이렇게 설계하지 않기 때문에 이 문제에 대해서는 고민안하셔도 될것 같네요.