Ինչպե՞ս կարող է տեղի ունենալ այն իրավիճակը, երբ ցրիվը ցածր առաջնահերթությամբ ստանում է ռեսուրսների հասանելիությունը բարձր առաջնահերթությամբ հերթից առաջ։

Դա կարող է տեղի ունենալ առաջնահերթությունների հակառակը փոխելու պատճառով:

Անհրաժեշտ է նշել, որ առաջնահերթությունների հակառակը փոխելու դեպքում, երբ ցածր առաջնահերթությամբ առաջադրանքը պահում է ռեսուրս (օրինակ, mutex), որը անհրաժեշտ է բարձր առաջնահերթությամբ առաջադրանքին, բարձր առաջնահերթությամբ առաջադրանքը բլոկվում է սպասելով ռեսուրսի ազատմանը: Միաժամանակ, միջին առաջնահերթությամբ առաջադրանքը կարող է լինել փոխհատուցված այլ առաջադրանքով, որը չի պահանջում այդ ռեսուրսը: Այսպիսով, միջին առաջնահերթությամբ առաջադրանքը կատարվում է, մինչդեռ ցածր առաջնահերթությամբ առաջադրանքը, որը պահում է ռեսուրսը, և բարձր առաջնահերթությամբ առաջադրանքը, որը բլոկված է, սպասում են: Իրականում, բարձր առաջնահերթությամբ առաջադրանքը սպասում է, մինչդեռ միջին և ցածր առաջնահերթությամբ առաջադրանքները ազատում են ռեսուրսը:

Առաջնահերթությունների հակառակը փոխելու խնդրի լուծումները՝

• Առաջնահերթությունների ժառանգություն (Priority Inheritance): Երբ ցածր առաջնահերթությամբ առաջադրանքը պահում է ռեսուրս, որը անհրաժեշտ է բարձր առաջնահերթությամբ առաջադրանքին, նրան ժամանակավոր վերապահվում է բարձր առաջնահերթության առաջադրանքի առաջնահերթությունը: Ռեսուրսի ազատումից հետո, առաջնահերթությունը վերադառնում է սկզբնականին:
• Առաջնահերթության տանիքի պրոտոկոլ (Priority Ceiling Protocol): Յուրաքանչյուր ռեսուրսին վերապահվում է "առաջնահերթության տանիք" — ամենաբարձր առաջնահերթությունը բոլոր առաջադրանքների միջև, որոնք կարող են օգտագործել այդ ռեսուրսը: Միայն այն դեպքում, եթե նրա ընթացիկ առաջնահերթությունը բարձր է, քան բոլոր զբաղեցրած ռեսուրսների տանիքի առաջնահերթությունը (ներառյալ այները, որոնք նա արդեն պահում է):

iOS-ում, Grand Central Dispatch (GCD) և Operation Queues ունեն մեխանիզմներ առաջնահերթությունների հակառակը նվազեցնելու համար, բայց բարդ սցենարներում, փակման դեպքում, նման իրավիճակներ դեռ կարող են առաջանալ, եթե սխալ օգտագործվեն։