글 수 83
이전에 하이텔 게제동에 올렸던 제 글입니다.
제 목:[답변] spinlock 관련자료:없음 [2415]
보낸이:유영천 (yuchi ) 2001-01-29 12:18 조회:251
win32의 스레드 동기화에선 criticalsection이든 event방식이든 mutex,
semaphor든 모두 내부적으론 waitfunc을 사용합니다.
다른 스레드가 점하고 있어 진입할 수 없는 상황이 되면 os가 이 스레드
를 스케쥴링 큐에서 빼고 먼저 진입한 스레드가 빠져나가거나 그에 상응
하는 이벤트가 발생할때까지 대기시킵니다.
따라서 다시 resume시키는것도 os가 해줍니다. 이 과정에서 딜레이가 상
당합니다.가장 빠르다는 크리티컬 섹션도 1000클럭은 우습게 날아갑니다.
많은 수의 스레드가 아주 짧은 시간동안 작업을 빈번하게 하는 경우가
최악의 시나리오가 되겠죠.실제 작업하는 시간보다 대기 시간이 길어지니
까요. 그래서 이런 경우 스핀락을 사용할 수 있습니다.
먼저 진입한 스레드가 있다면 이 스레드가 빠져나갈때까지 락카운트(구
현방법에 따라서는 다른게 될수도 있습니다)를 체크하며 루프를 도는
것입니다.크리티컬 섹션에선 InitializeCriticalSectionAndSpinCount()함수
로 스핀락을 설정해줄 수 있고 아래 제가 올린 소스로 그냥 만들어도
됩니다.단 이 경우는 두 스레드가 실제로 동시에 동작해야 빠른 진입
이 가능한 것이므로 멀티 cpu에서 의미가 있겠죠.싱글에선 진입을 빨리
시킬순 있을지 몰라도 순간적으로 cpu부하가 커집니다.
제 목:[답변] spinlock 관련자료:없음 [2415]
보낸이:유영천 (yuchi ) 2001-01-29 12:18 조회:251
win32의 스레드 동기화에선 criticalsection이든 event방식이든 mutex,
semaphor든 모두 내부적으론 waitfunc을 사용합니다.
다른 스레드가 점하고 있어 진입할 수 없는 상황이 되면 os가 이 스레드
를 스케쥴링 큐에서 빼고 먼저 진입한 스레드가 빠져나가거나 그에 상응
하는 이벤트가 발생할때까지 대기시킵니다.
따라서 다시 resume시키는것도 os가 해줍니다. 이 과정에서 딜레이가 상
당합니다.가장 빠르다는 크리티컬 섹션도 1000클럭은 우습게 날아갑니다.
많은 수의 스레드가 아주 짧은 시간동안 작업을 빈번하게 하는 경우가
최악의 시나리오가 되겠죠.실제 작업하는 시간보다 대기 시간이 길어지니
까요. 그래서 이런 경우 스핀락을 사용할 수 있습니다.
먼저 진입한 스레드가 있다면 이 스레드가 빠져나갈때까지 락카운트(구
현방법에 따라서는 다른게 될수도 있습니다)를 체크하며 루프를 도는
것입니다.크리티컬 섹션에선 InitializeCriticalSectionAndSpinCount()함수
로 스핀락을 설정해줄 수 있고 아래 제가 올린 소스로 그냥 만들어도
됩니다.단 이 경우는 두 스레드가 실제로 동시에 동작해야 빠른 진입
이 가능한 것이므로 멀티 cpu에서 의미가 있겠죠.싱글에선 진입을 빨리
시킬순 있을지 몰라도 순간적으로 cpu부하가 커집니다.