"세마포어를 사용하여 N 개의 프로세스 장벽 구현"으로 수정

Question

최근에이 문제는 첫 번째 리더/라이터 문제와 비슷합니다.

Implementing an N process barrier using semaphores

나는 그것을 수정하려고하고 있는지가 재사용하고 제대로 작동 할 수했다.

n = the number of threads 
count = 0 
mutex = Semaphore(1) 
barrier = Semaphore(0) 


mutex.wait() 
count = count + 1 
if (count == n){ barrier.signal()} 
mutex.signal() 

barrier.wait() 

mutex.wait() 
count=count-1 
barrier.signal() 
if(count==0){ barrier.wait()} 
mutex.signal() 

이 정보가 맞습니까?

내가 발견하지 못한 실수가 있는지 궁금합니다.

Answer 1

의사 코드가 장벽을 올바르게 초기 상태로 되돌립니다. 하찮은 제안 : 방법에 함정이있을 수있다,

if(count!=0){ barrier.signal()} //if anyone left pending barrier, release it 

그러나 더 읽기 이럴와

barrier.signal() 
if(count==0){ barrier.wait()} 

교체는 장벽은 재사용된다. 설명 된 장벽에는 두 가지 상태가 있습니다.

1. 모든 스레드가 보류 상태가 될 때까지 중지합니다. 일부 스레드가 재개되고, 다른 하나는 이미 다시 첫 번째 단계에 충돌 반면, : 그들 모두

을 혼합에 대한 보호가 없습니다을 실행 때까지 각 스레드를 다시 시작

. 예를 들어, 몇 가지 물건을 처리하고 장벽을 동기화하는 스레드가 있습니다. 각 스레드 본문은 다음과 같습니다

while (!exit_condition) { 
    do_some_stuff(); 
    pend_barrier(); // implementation from current question 
} 

프로그래머는 기대 do_some_stuff()에 대한 호출의 수는 모든 스레드에 대해 동일합니다. 타이밍에 따라 어떤 일이 발생할 수도 있고 그렇지 않을 수도 있습니다. 모든 스레드가 장벽을 떠나기 전에 장벽에서 해제 된 첫 번째 스레드가 do_some_stuff() 계산을 완료하므로 두 번째로 보류 상태가됩니다. 결과적으로 그는 현재의 장벽 릴리스 반복에서 다른 스레드와 함께 릴리스 될 것이고 do_some_stuff()에 대해 적어도 한 번 더 호출 할 것입니다.