Objective-C를 처음 사용했습니다. @synchronized은 언제 사용해야하며 언제 사용해야합니까? lock/unlock? 제 배경은 주로 자바입니다. Java에서 명시 적 잠금을 사용하면 더 복잡하고 광범위하며 유연한 작업 (릴리스 순서와 함께)을 수행 할 수 있으며 synchronized 키워드는 잠금을 블록 구조로 사용하고 그들은 또한 그들이 획득 된 방법의 역순으로 발표해야합니다. Objective-C에서 동일한 근거가 유지됩니까?@synchronized 대 lock/unlock
많은 사람들이 임의의 순서로 잠금/잠금 해제를 버그가 아닌 기능으로 간주합니다. 즉, 꽤 쉽게 교착 상태가됩니다.
어쨌든 @synchonized(), -lock/-unlock 또는 다른 뮤텍스 사이에는 약간의 차이가 있습니다 (범위에 대한 세부 정보는 제외). 그들은 비싸고, 허술하며, 오류가 발생하기 쉽고, 어쨌든 (스레드의 복잡성을 제외하면) 단일 스레드 솔루션과 유사한 성능을 제공합니다.
새로운 인기는 대기열입니다. 대기열은 일반적으로 대부분의 호출을 설명하는 "빠른 경로"작업에 대한 시스템 호출이 필요하지 않기 때문에 훨씬 가벼운 경향이 있습니다. 그들은 또한 의도를 표현하는 경향이 있습니다.
그랜드 센트럴 디스패치 또는 NSOperationQueue입니다. 후자는 현재 OS 릴리스에서 전자에 기반합니다. GCD의 API는 낮은 레벨 인 경향이 있지만 매우 강력하고 놀라 울 정도로 간단합니다. NSOperationQueue은 상위 레벨이므로 종속성 등을 직접 표현할 수 있습니다.
나는 Cocoa concurrency guide으로 시작하는 것이 좋습니다.
일반적으로 정확합니다. @synchronized은 지정된 객체에 "첨부"된 잠금을 사용합니다 (@synchronized 지시어에 언급 된 객체는 잠금 일 필요는 없습니다). Java에서와 마찬가지로, 새로운 블록을 정의하고, 블록을 정상적으로 또는 예외를 통해 남겨 둘지 여부에 관계없이, 잠금은 처음에 취해지고 종료 시점에 해제됩니다. 따라서 추측 하듯이 잠금 장치는 획득과 반대 순서로 해제됩니다.
고마워요! 임의의 잠금/잠금 해제에 대해 동의합니다. 나는 이것을 할 필요가있는 경우를 찾지 못했습니다. 또한 대기열을 언급 해 주셔서 감사합니다. 나는 그들이 그 방향으로 갔다는 것을 알지 못했습니다. 나는 내 머리 속에서 그 아이디어를 가지고 놀았으며 그것이 실제적이고 실행 가능한 해결책이라는 것을 알고있다. –
도와 드리겠습니다. 실행 가능한 것 이상으로, 모든 것에 대해 대기열의 방향으로 이동하고 있습니다. 대기열은 잠금을 완전히 대체 할 수 있으며 일반적으로 디버그하는 것이 훨씬 쉽습니다. – bbum