2013-02-12 2 views
0

현재 값이 사전에서 변경 될 때까지 차단하는 메소드를 설계하려고합니다. 여기 WaitForOpenSpot 메서드를 사용하고 있습니다. 이것은 대략적인 스케치 일뿐입니다. 현재 스레드로부터 안전하지 않다는 것을 알고 있습니다. 나중에 잠금/잠금 해제를 추가 할 것입니다. 지금은 이것을하기위한 더 좋은 방법이 있는지 알고 싶었습니다. 다른 제안 사항도 인정 될 것입니다.사전의 값이 변경 될 때까지 차단 방법 설계

Class AccountStatus 
{ 
    static bool OpenSpot = false; 

    static private Dictionary<String, int> Transfer = InitializeContainer(); 

    static Dictionary<String , int> InitializeContainer() 
    { 
     Dictionary<String, int> Transfer = new Dictionary<String, int>() 
     Transfer.add("stat",0); 
    } 

    static void Changestatus(string str , int val) //str = stat 
    { 
     Transfer[str] = val; 
     if(val == 1) 
     { 
      OpenSpot = true 
     }   
    } 

    static void WaitForOpenSpot() 
    { 
     while(!OpenSpot) 
     { 
      Thread.sleep(2); 
     } 
    } 
}//end class 
+0

.Net 4.0 이상을 사용할 수 있습니까? – user7116

+0

예 .net 4.0 - VS2010 – Rajeshwar

답변

2

AutoResetEvent 클래스를 살펴보십시오.

사용자 코드에서 채택하는 것은 당신에게 거친 예 (컴파일하지 않을 수 있습니다)을 얻었다 :이 Monitor.Wait/Monitor.PulseAll를 사용하는 것처럼 뭔가

private static AutoResetEvent resetEvent = new AutoResetEvent(false); 

static void WaitForOpenSpot() 
{ 
    resetEvent.WaitOne(); 
} 

static void ChangeStatus(string str, int val) 
{ 
    Transfer[str] = val; 
    if (val == 1) 
    { 
     resetEvent.Set(); 
    } 
} 
+0

제안에 감사드립니다. 그러나 Isnt AutoResetEvent가 여기에 정적이라고 가정하십니까? – Rajeshwar

+0

그래, 응답이 편집되었습니다. – jeuton

0

일반적인 패턴. 이러한 메소드를 사용하려면 잠금 내에서 만 변경할 수있는 대기 조건을 정의하고 해당 조건을 변경할 수있는 코드가 있으면 잠금 후 PulseAll을 수행해야합니다.

예 : 사전 myDict;

//Code that waits for magic key value: 
lock(myDict) 
{ 
    int myNumber; 
    while (!myDict.TryGetValue(myKey, out myNumber) || myNumber < valueOfInterest) 
     Monitor.Wait(myDict); 
} 

//Code that changes anything in myDict: 
lock(myDict) 
{ 
    myDict[theKey] = theValue; 
    Monitor.PulseAll(myDict); 
} 

사전에서 언제든지 아무것도 변경, 특정 키를 기다리는 모든 대기 스레드가 특정 값이 하나 하나, 그것은 수행 여부를 확인하기 위해 확인 중 진행 또는 대기로 돌아갑니다 잡아 .

Monitor.Wait이 가끔씩 자발적으로 펄싱되지 않으면이 코드의 정확성에 영향을 미치지 않습니다. Monitor.Wait은 일반적으로 자발적으로 깨어나지는 않겠지 만 올바르게 작성된 코드는 일반적으로 이러한 깨우기를 허용 할 수 있으며 이러한 깨우기에 의해 손상 될 코드는 일반적으로 다른 방식으로도 손상됩니다.

관련 문제