1. 가정에서가 아니라 실험 결과에서 나온 것입니다. 그런데 378 페이지의 실험에서도 확인되었습니다.
2. 378페이지의 코드는 원자적 액세스만 제공합니다. 작업 실행 대기열이 빌드되지 않습니다. 일부 작업이 매우 오랫동안 실행되지 않을 수 있습니다.
대기열은 시스템에 의해 구축됩니다. 실행 순서는 보장되지 않습니다. 오랫동안 충족되지 않을 수 있습니다. 공유 리소스에 액세스하기 위한 특별한 순서를 의미하는 이 잘못된 알고리즘에 또 다른 방법이 있습니까? 틱이 언제 다른 차트에 올지, 언제 TS에 신호가 있는지 등을 모르십니까? 그렇다면 공유 리소스에 액세스하는 순서는 무엇입니까? 모듈이 이 알고리즘에서 대기 중이면 올바른 것입니다(기다립니다). 그러나 알고리즘을 구축한다는 의미에서는 정확하지 않습니다.
1. 대기열은 시스템에 의해 구축됩니다. 2. 실행 순서는 보장되지 않습니다. 오랫동안 충족되지 않을 수 있습니다.
3. 무엇, 공유 리소스에 액세스하기 위한 특별한 순서를 의미하는 이 잘못된 알고리즘에 다른 방법이 있습니까?
4. 언제 다른 차트에 틱이 올지, 언제 TS에 신호가 올지 모르십니까?
5. 그렇다면 공유 리소스에 대한 액세스는 어떤 순서로 발생합니까? 모듈이 이 알고리즘에서 대기 중이면 올바른 것입니다(기다립니다). 그러나 알고리즘을 구축한다는 의미에서 정확하지는 않습니다.
6. 리히터를 읽으십시오. 그는 이미 모든 것을 올바르게 설명했습니다.
자, 두 번째 라운드로 가자.
1. 시스템은 어떤 작업이 실제로 완료되었고 어떤 작업이 작업 자체 내에서 거부되었는지 알지 못합니다. 저것들. 시스템 입장에서는 작업이 완료된 것이고, 우리 입장에서는 하나의 작업만 남겨두고 나머지는 차단했기 때문에 우리 입장에서는 하나의 작업만 완료한 것이다. 따라서 정기적인 작업 순서를 보장하는 것이 우리의 임무입니다.
1, 2. 큐가 만들어지지만 순서가 보장되지 않는다)))) 글쎄요, 줄을 서지 않고 원자적 접근만 제공한다는 뜻이고,
3. 왜 안되나요? 모든 것은 프로그래머의 손에 있습니다.
4. 모든 것은 프로그래머의 손에 달려 있습니다.
5. 내가 서 있다면. 하지만 그럴 가치가 없습니다. 작업은 대기열에 포함되지 않고 실행 여부만 결정됩니다. 다음 zapruska (틱)에서, 그것은 순전히 헛소리에서 ... 누가 미리 벌지 알 수 없으며 나머지는 배 이상입니다.
6. 왜? 보시다시피 스마트 북을 읽는 것이 항상 유용한 것은 아닙니다. 당신은 그것을 읽은 것 같지만 대화의 내용을 이해하지 못합니다. 읽어보진 않았지만 이해합니다.
1. 시스템은 어떤 작업이 실제로 완료되었고 어떤 작업이 작업 자체 내에서 거부되었는지 알지 못합니다. 저것들. 시스템 관점에서는 작업이 완료되고, 우리는 하나의 작업만 남겨두고 나머지는 차단하였기 때문에 우리의 관점에서는 하나의 작업만 완료되었습니다. 따라서 정기적인 작업 순서를 보장하는 것이 우리의 임무입니다.
1, 2. 큐가 만들어지지만 순서가 보장되지 않는다)))) 글쎄요, 줄을 서지 않고 원자적 접근만 제공한다는 뜻이고,
3. 왜 안되나요? 모든 것은 프로그래머의 손에 있습니다.
4. 모든 것은 프로그래머의 손에 달려 있습니다.
5. 할 수만 있다면. 하지만 그럴 가치가 없습니다. 작업은 대기열에 포함되지 않고 실행 여부만 결정됩니다. 다음 zapruska (틱)에서, 그것은 순전히 헛소리에서 ... 누가 미리 벌지 알 수 없으며 나머지는 배 이상입니다.
6. 왜? 보시다시피 스마트 북을 읽는 것이 항상 유용한 것은 아닙니다. 당신은 그것을 읽은 것 같지만 대화가 무엇인지 이해하지 못합니다. 읽어보진 않았지만 이해합니다.
이것은 복잡한 코드에 대한 혼란입니다. 단순화하는 대신 대기열을 해결하기 위해 복잡한 코드를 감습니다.
리히터도 오랫동안 책을 읽고 싶지 않았습니다. 하지만 그래도 읽었습니다. 다중 스레드 응용 프로그램을 구축하기 위한 규칙은 간단합니다. 가장 중요한 것은 단순화하십시오. 이것은 리히터의 결론입니다. 그렇지 않으면 작성하는 것보다 디버그하는 데 더 많은 시간이 걸립니다. 그건 그렇고, 나는 전에 다중 스레드 응용 프로그램을 디버깅할 필요가 없었습니다. 모든 것이 즉시 작동했습니다.
이것은 복잡한 코드에 대한 혼란입니다. 단순화하는 대신 대기열을 해결하기 위해 복잡한 코드를 감습니다.
리히터도 오랫동안 책을 읽고 싶지 않았습니다. 하지만 그래도 읽었습니다. 다중 스레드 응용 프로그램을 구축하기 위한 규칙은 간단합니다. 가장 중요한 것은 단순화하십시오. 이것은 리히터의 결론입니다. 그렇지 않으면 작성하는 것보다 디버그하는 데 더 많은 시간이 걸립니다. 그건 그렇고, 나는 전에 다중 스레드 응용 프로그램을 디버깅할 필요가 없었습니다. 모든 것이 즉시 작동했습니다.
어떤 종류의 무감각? 복잡한 코드란 무엇입니까? 이것은 작업에 필요한 최소 요구 사항입니다. 그리고 당신의 접근 방식은 누보입니다. 수행되는 모든 작업은 보장된 안정성 으로 작동해야 하며 임의 정렬의 효과에 의존해서는 안 됩니다.
리히터는 어떻습니까? 다중 스레드 시스템은 어떻습니까? 대화가 시작된 원래 작업을 기억하십시오.
어떤 종류의 무감각? 복잡한 코드란? 이것은 작업에 필요한 최소 요구 사항입니다. 그리고 당신의 접근 방식은 누보입니다. 수행되는 모든 작업은 보장된 안정성 으로 작동해야 하며 임의 정렬의 효과에 의존해서는 안 됩니다.
리히터는 어떻습니까? 다중 스레드 시스템은 어떻습니까? 대화가 시작된 원래 작업을 기억하십시오.
좋아요, 원하는 대로 쓰세요. 나는 설득하지 않을 것이다. 그는 그가 할 수 있는 모든 것을 말했다.
처음에 작업은 예금의 크기에 액세스하기 위해 동기화하는 것이 었습니다. 내가 작성한 코드는 이것을 완벽하게 해결합니다. 모든 것이 원래대로입니다. 최소한의 리소스 액세스 시간 . 모든 모듈은 몇 가지 예외를 제외하고 요청과 거의 동일한 순서로 처리됩니다. 중요하지 않습니다.
당신을 위해 특별히 제작되었습니다. 이것은 다중 스레드 응용 프로그램에 대한 규칙 중 하나입니다. 오랫동안 실행되는 스레드가 있는 경우 스레드를 대기열에 넣어야 하며 이것이 중요하며 이는 잘못된 알고리즘입니다. 다시 해야 합니다. 당신은 그렇게 쓸 수 없습니다. 하지만, 당신은 무엇이든 할 수 있습니다. 쓰다...
1. 좋아요, 원하는 대로 쓰세요. 나는 설득하지 않을 것이다. 그는 그가 할 수 있는 모든 것을 말했다.
2. 초기 작업은 입금액의 크기에 대한 접근을 동기화하는 것이었습니다.
3. 제가 작성한 코드는 이것을 완벽하게 해결합니다. 모든 것이 원래대로입니다. 최소한의 리소스 액세스 시간 . 모든 모듈은 요청과 거의 동일한 순서로 처리됩니다.
4. 특별히 할당된 것. 이것은 다중 스레드 응용 프로그램에 대한 규칙 중 하나입니다. 오랫동안 실행되는 스레드가 있는 경우 스레드를 대기열에 넣어야 하며 이것이 중요하며 이는 잘못된 알고리즘입니다. 다시 해야 합니다. 당신은 그렇게 쓸 수 없습니다. 하지만 무엇이든 할 수 있습니다. 쓰다...
1. 가정에서가 아니라 실험 결과에서 나온 것입니다. 그런데 378 페이지의 실험에서도 확인되었습니다.
2. 378페이지의 코드는 원자적 액세스만 제공합니다. 작업 실행 대기열이 빌드되지 않습니다. 일부 작업이 매우 오랫동안 실행되지 않을 수 있습니다.
대기열은 시스템에 의해 구축됩니다. 실행 순서는 보장되지 않습니다. 오랫동안 충족되지 않을 수 있습니다. 공유 리소스에 액세스하기 위한 특별한 순서를 의미하는 이 잘못된 알고리즘에 또 다른 방법이 있습니까? 틱이 언제 다른 차트에 올지, 언제 TS에 신호가 있는지 등을 모르십니까? 그렇다면 공유 리소스에 액세스하는 순서는 무엇입니까? 모듈이 이 알고리즘에서 대기 중이면 올바른 것입니다(기다립니다). 그러나 알고리즘을 구축한다는 의미에서는 정확하지 않습니다.
리히터를 읽으십시오. 그는 이미 모든 것을 올바르게 설명했습니다.
1. 대기열은 시스템에 의해 구축됩니다. 2. 실행 순서는 보장되지 않습니다. 오랫동안 충족되지 않을 수 있습니다.
3. 무엇, 공유 리소스에 액세스하기 위한 특별한 순서를 의미하는 이 잘못된 알고리즘에 다른 방법이 있습니까?
4. 언제 다른 차트에 틱이 올지, 언제 TS에 신호가 올지 모르십니까?
5. 그렇다면 공유 리소스에 대한 액세스는 어떤 순서로 발생합니까? 모듈이 이 알고리즘에서 대기 중이면 올바른 것입니다(기다립니다). 그러나 알고리즘을 구축한다는 의미에서 정확하지는 않습니다.
6. 리히터를 읽으십시오. 그는 이미 모든 것을 올바르게 설명했습니다.
자, 두 번째 라운드로 가자.
1. 시스템은 어떤 작업이 실제로 완료되었고 어떤 작업이 작업 자체 내에서 거부되었는지 알지 못합니다. 저것들. 시스템 입장에서는 작업이 완료된 것이고, 우리 입장에서는 하나의 작업만 남겨두고 나머지는 차단했기 때문에 우리 입장에서는 하나의 작업만 완료한 것이다. 따라서 정기적인 작업 순서를 보장하는 것이 우리의 임무입니다.
1, 2. 큐가 만들어지지만 순서가 보장되지 않는다)))) 글쎄요, 줄을 서지 않고 원자적 접근만 제공한다는 뜻이고,
3. 왜 안되나요? 모든 것은 프로그래머의 손에 있습니다.
4. 모든 것은 프로그래머의 손에 달려 있습니다.
5. 내가 서 있다면. 하지만 그럴 가치가 없습니다. 작업은 대기열에 포함되지 않고 실행 여부만 결정됩니다. 다음 zapruska (틱)에서, 그것은 순전히 헛소리에서 ... 누가 미리 벌지 알 수 없으며 나머지는 배 이상입니다.
6. 왜? 보시다시피 스마트 북을 읽는 것이 항상 유용한 것은 아닙니다. 당신은 그것을 읽은 것 같지만 대화의 내용을 이해하지 못합니다. 읽어보진 않았지만 이해합니다.
자, 두 번째 라운드로 가자.
1. 시스템은 어떤 작업이 실제로 완료되었고 어떤 작업이 작업 자체 내에서 거부되었는지 알지 못합니다. 저것들. 시스템 관점에서는 작업이 완료되고, 우리는 하나의 작업만 남겨두고 나머지는 차단하였기 때문에 우리의 관점에서는 하나의 작업만 완료되었습니다. 따라서 정기적인 작업 순서를 보장하는 것이 우리의 임무입니다.
1, 2. 큐가 만들어지지만 순서가 보장되지 않는다)))) 글쎄요, 줄을 서지 않고 원자적 접근만 제공한다는 뜻이고,
3. 왜 안되나요? 모든 것은 프로그래머의 손에 있습니다.
4. 모든 것은 프로그래머의 손에 달려 있습니다.
5. 할 수만 있다면. 하지만 그럴 가치가 없습니다. 작업은 대기열에 포함되지 않고 실행 여부만 결정됩니다. 다음 zapruska (틱)에서, 그것은 순전히 헛소리에서 ... 누가 미리 벌지 알 수 없으며 나머지는 배 이상입니다.
6. 왜? 보시다시피 스마트 북을 읽는 것이 항상 유용한 것은 아닙니다. 당신은 그것을 읽은 것 같지만 대화가 무엇인지 이해하지 못합니다. 읽어보진 않았지만 이해합니다.
이것은 복잡한 코드에 대한 혼란입니다. 단순화하는 대신 대기열을 해결하기 위해 복잡한 코드를 감습니다.
리히터도 오랫동안 책을 읽고 싶지 않았습니다. 하지만 그래도 읽었습니다. 다중 스레드 응용 프로그램을 구축하기 위한 규칙은 간단합니다. 가장 중요한 것은 단순화하십시오. 이것은 리히터의 결론입니다. 그렇지 않으면 작성하는 것보다 디버그하는 데 더 많은 시간이 걸립니다. 그건 그렇고, 나는 전에 다중 스레드 응용 프로그램을 디버깅할 필요가 없었습니다. 모든 것이 즉시 작동했습니다.
이것은 복잡한 코드에 대한 혼란입니다. 단순화하는 대신 대기열을 해결하기 위해 복잡한 코드를 감습니다.
리히터도 오랫동안 책을 읽고 싶지 않았습니다. 하지만 그래도 읽었습니다. 다중 스레드 응용 프로그램을 구축하기 위한 규칙은 간단합니다. 가장 중요한 것은 단순화하십시오. 이것은 리히터의 결론입니다. 그렇지 않으면 작성하는 것보다 디버그하는 데 더 많은 시간이 걸립니다. 그건 그렇고, 나는 전에 다중 스레드 응용 프로그램을 디버깅할 필요가 없었습니다. 모든 것이 즉시 작동했습니다.
어떤 종류의 무감각? 복잡한 코드란 무엇입니까? 이것은 작업에 필요한 최소 요구 사항입니다. 그리고 당신의 접근 방식은 누보입니다. 수행되는 모든 작업은 보장된 안정성 으로 작동해야 하며 임의 정렬의 효과에 의존해서는 안 됩니다.
리히터는 어떻습니까? 다중 스레드 시스템은 어떻습니까? 대화가 시작된 원래 작업을 기억하십시오.
말하다! Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim" );
말하다! Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim" );
어떤 종류의 무감각? 복잡한 코드란? 이것은 작업에 필요한 최소 요구 사항입니다. 그리고 당신의 접근 방식은 누보입니다. 수행되는 모든 작업은 보장된 안정성 으로 작동해야 하며 임의 정렬의 효과에 의존해서는 안 됩니다.
리히터는 어떻습니까? 다중 스레드 시스템은 어떻습니까? 대화가 시작된 원래 작업을 기억하십시오.
좋아요, 원하는 대로 쓰세요. 나는 설득하지 않을 것이다. 그는 그가 할 수 있는 모든 것을 말했다.
처음에 작업은 예금의 크기에 액세스하기 위해 동기화하는 것이 었습니다. 내가 작성한 코드는 이것을 완벽하게 해결합니다. 모든 것이 원래대로입니다. 최소한의 리소스 액세스 시간 . 모든 모듈은 몇 가지 예외를 제외하고 요청과 거의 동일한 순서로 처리됩니다. 중요하지 않습니다.
당신을 위해 특별히 제작되었습니다. 이것은 다중 스레드 응용 프로그램에 대한 규칙 중 하나입니다. 오랫동안 실행되는 스레드가 있는 경우 스레드를 대기열에 넣어야 하며 이것이 중요하며 이는 잘못된 알고리즘입니다. 다시 해야 합니다. 당신은 그렇게 쓸 수 없습니다. 하지만, 당신은 무엇이든 할 수 있습니다. 쓰다...
1. 좋아요, 원하는 대로 쓰세요. 나는 설득하지 않을 것이다. 그는 그가 할 수 있는 모든 것을 말했다.
2. 초기 작업은 입금액의 크기에 대한 접근을 동기화하는 것이었습니다.
3. 제가 작성한 코드는 이것을 완벽하게 해결합니다. 모든 것이 원래대로입니다. 최소한의 리소스 액세스 시간 . 모든 모듈은 요청과 거의 동일한 순서로 처리됩니다.
4. 특별히 할당된 것. 이것은 다중 스레드 응용 프로그램에 대한 규칙 중 하나입니다. 오랫동안 실행되는 스레드가 있는 경우 스레드를 대기열에 넣어야 하며 이것이 중요하며 이는 잘못된 알고리즘입니다. 다시 해야 합니다. 당신은 그렇게 쓸 수 없습니다. 하지만 무엇이든 할 수 있습니다. 쓰다...
1. 나는 당신에게 질문이 없었습니다. 당신의 임무를 과대 평가하지 마십시오.
2. 좋아하는 단어 "동기화"? 병렬 작업을 순차적으로 실행하는 작업이 있었습니다.
3. 해결되지만 완벽하지는 않습니다. Nuber-lamer 방법이 해결됩니다.
4. 쿠쿠 일어나!