[Essay][Prog] Multi-Threading SW Programming 방법론에 대한 단상.

Multi-Threading(이하 MT)  SW Programming시 동기화는 무엇보다 중요한 이슈가 된다.
생각해보면, 동기화가 문제가 되는 이유는, Programming Language의 기본 전제가 “필요한 곳에 동기화를 한다.” 이기 때문이다.
이런 정책에 100% 동의한다. MT을 통해, HW 자원을 효율적으로 사용하고자 한다면 더더욱 그러하다.
그런데, 만약 상당히 많은 부분을 서로 공유하는 어떤 MT SW가 있다고 가정한다면 (그런 SW는 디자인 자체가 잘못된 것이라는 등의 이야기는 일단 접어두자.) 어떨까?
이런 경우 “필요한 곳에 동기화”란 개념으로 보면, 너무 많은 “필요한 곳”이 존재하게 되므로, 쉽지 않다.
이럴 경우, 차라리 개념을 “필요한 곳에서 rescheduling”이라는 걸로 개념을 바꾸어 보는건 어떻까?
일단 다른 측면들은 모두 차치하고서라도, Programming은 좀더 쉬워질 것 같지 않은가?
이런 식의 개념을 지원하도록 SW구조를 잡는 것은 그리 어려운 일은 아니다.
물론, HW 자원을 효과적으로 쓰도록 만들기는 앞의 개념에 비해서 상당히 더 어려울 것이다.
결국 아래와 같은 Trade-off가 발생한다.

“HW자원의 효율적인 사용 vs. Programming의 단순와”

너무 무식한 방법이라고 비판할 수도 있겠지만, Performance가 큰 문제가 되지 않고, Async한 동작자체가 중요한 경우라면, 충분히 한번 고려해 볼만하지 않은가? 일단 Bug는 많이 줄일 수 있으니…

Advertisements

[Study] Ascending Stack Vs. Descending Stack

Ascending Stack : The stack grows upwards, starting from a low address and progressing to a higher address.
Descending Stack : The stack grows downwards, starting with a high address and progressing to a lower one.

Fundamentally, these two are same. But, I prefer descending stack, because when stack is broken, mostly post-stack-section(higher memory address) tends to be broken. So,

– [case1 : current stack has enough free space]
Descending stack is better to detect stack-corruption than ascending stack.

void func_test(void)
{
    (omitted...)
    char a[10]; // ---(*1)
    (omitted...)
    memcpy(a, data, len); // len > 10 ---(*2)
   (omitted...)
}

If stack space after (*1) is not used, then even if stack is corrupted, it is very difficult to detect in ascending stack.
(because, no one uses corrupted area.) So, debugging is more difficult.

– [case2 : current stack is almost pull]
In descending stack, usually, corrupting stack of specific thread(Thread A) affects it’s own behavior firstly. So, it is easier to debug – same with [case1].
In ascending stack, corrupting stack may affects to other thread’s stack – thread whose stack is just next (higher address) of Thread A – firstly with high possibility (especially, if several stacks are adjacent in memory space). This usually leads to debugging-nightmare