나 어제 하루 죙일 잠자면서 "내가 어쩌다가 이런 거대한 장벽을 만났는가"


곰곰히 곱씹어봤거든??


그러면서


하나 하나씩 해치워나갈 생각을 해봤어.



그랬더니 이런 결과물이 나오더라고.


아마, 찍먹하다가 못따라가겠어서 드랍친, "멀티프로세서 동기화"수업에서 나름 찍먹해보고 배운것들을 토대로 발전시켜나갔을텐데,





Concurrent Object?? 여하튼 각각의 객체마다 그들의 Concurrency 에 대한 성질을 규명시켜줄 필요가 있어.



변경에는 타이밍이 있다.



내가 보고 있는 OS의 경우에는 세가지로 나뉘어.




1. 인터럽트에 의한 변경

: 커널권한코드에서도, 유저권한 코드에서도 언제든지 변경이 일어날 수 있는 대상이야.


명시적인 차단은 cli 와 sti 로 이루어져. (커널권한에서밖에 사용할 수 없음)



2. 스케쥴링에 의한 변경

: 이것은, 유저프로세스 내부에서는 인터럽트와 마찬가지로, 언제든지 변경이 일어날수 있는 대상이고,

커널권한 프로세스에서는 내가 직접 스케쥴링을 다른 컨텍스트에게 넘겨주지 않는 이상, 변경되지 않을거라는 보장이 있어.


또한, 스케쥴링에 의한 변경은 lock 이라는 데이터구조를 소프트웨어에서 구현해 준다면, 변경을 의도적으로 막을 수 있어.

다만 이 lock이라는 개념은 인터럽트 단계에서는 진행하지 않음.

lock 은 sleep으로 구현하면서 스케쥴링을 받자마자 바로 다른녀석한테 넘겨주는 방식으로 구현하지만

인터럽트를 실행중에 스케쥴링을 다른녀석한테 넘겨주는 경우는 나는 본적이 없어.



3. 멀티쓰레딩에 의한 변경

: 이 부분은 현재 내가 다루지 않는 부분이지만.... 인터럽트에 의한 변경보다도 더 빡센 변경사항이 됨. 일단은 없는걸로 간주하겠음.






그렇다면 모든 객체에 대해서,


0. 어떤 조건 하에서

1. 인터럽트에 의해 / 스케쥴링에 의해

2. 어떤 필드가 변경될 수 있는가


를 명시해주면 돼.



근데, 이걸 명시하려고 하다보면

nested 가 발생해.



예를 들면 이런거야.



request 라는 객체는,


해당 device가 하드디스크를 가리킬 경우,

인터럽트에 의해서,

bh -> b.update 가 변경될 수 있다.



라는 게 있다고 해봐. (이런 것들이 무지하게 많아.)


근데, 저거는 bh 필드의 내부 필드가 변경되었기 때문에 다른말로는



bh 라는 객체는,


해당 device 가 하드디스크이며,

리퀘스트 큐 안에 들어있는 경우, (그리고 이는 필연적으로 bh의 lock 이 걸려있다는 것을 내포함)


인터럽트에 의해서

b.update 가 변경될 수 있다.



이런식으로 nested 되어 있거든,



거기다가 조건절 또한 nested 가 이루어져있다는것을 알 수 있음.



그니까 저런걸 이제 잘 조합하면,



bh를 unlock 하고 나오면,

아 b.update 가 변경되는 상황은 아니다 (다른 추가 명제들도 전부 따져봐야하는거긴함)



이런식으로 concurrency를 따질 수 있게 되는거야.





결국



모~~~~~~든 명제를 전부 기입해야돼.



그리고


해당 오브젝트 중심으로


해당 오브젝트의 성질을 기반으로,

무엇이 변경되지 않는 성질이고 무엇이 어느단계에서 변경될 수 있는 성질인지를 알 수 있어.







이걸


"자동화 할 수 있어"




비쥬얼라이즈 할 수 있다고