Ես կարող եմ գտնել հին հղումներ և SO պատասխանները, որոնք ասում են, որ Thread.yield()-ի վարքագիծը տարբերվում է ըստ հարթակի: Այս պատասխանը ցույց է տալիս, որ դա պայմանավորված է նրանով, որ վարքագիծը իրականում նշված չէ:
Արդյո՞ք Java-ի ժամանակակից տարբերակների դեպքում է, որ Thread.yield() վարքագիծը տարբերվում է ըստ հարթակի:
Խմբագրել
Ես արդեն կարդացել եմ փաստաթղթերը: Ես հասկանում եմ, թե ինչ է դա ենթադրում: Ես հարցնում եմ իրական պահվածքի մասին:
Java 8 API-ից (վերջին ոչ բետա մինչ օրս):
Հուշում ժամանակացույցին, որ ընթացիկ շարանը պատրաստ է զիջել պրոցեսորի ներկայիս օգտագործումը: Ժամանակացույցն ազատ է անտեսելու այս հուշումը:
Եկամտաբերությունը էվրիստիկ փորձ է՝ բարելավելու հարաբերական առաջընթացը շղթաների միջև, որոնք հակառակ դեպքում չափազանց կօգտագործեն պրոցեսորը: Դրա օգտագործումը պետք է զուգակցվի մանրամասն պրոֆիլավորման և չափանիշի հետ՝ ապահովելու համար, որ այն իրականում ունենա ցանկալի ազդեցություն:
Հազվադեպ է տեղին է օգտագործել այս մեթոդը: Այն կարող է օգտակար լինել վրիպազերծման կամ փորձարկման նպատակներով, որտեղ այն կարող է օգնել վերարտադրել սխալները մրցավազքի պայմանների պատճառով: Այն կարող է նաև օգտակար լինել միաժամանակյա կառավարման կառուցվածքներ նախագծելիս, ինչպիսիք են java.util.concurrent.locks փաթեթում:
Հետևանքները հետևյալն են.
Նույնիսկ եթե Thread.yield() վարքագծի ճշգրիտ մանրամասները տարբեր են տարբեր հարթակներում, մեթոդի կանչը հիմնականում ոչինչ չի անում:
Դուք անվանում եք այն, և այն ոչինչ չի անում, և այն վերադարձնում է հնարավորինս արագ մոդուլով այն փաստը, որ այն կարող է կամ չավարտել թեմայի ընթացիկ ժամանակային հատվածը:
Արդյո՞ք դա «միջհարթակային ականապատ դաշտ է»:
Եթե դուք գրում եք կոդ, որը չի աշխատի, քանի դեռ Thread.yield()-ն իրականում չի ավարտում զանգահարողի ժամանակի հատվածը, ապա դուք գրել եք հատուկ հարթակի կոդը: Բայց Java-ն, հավանաբար, չպետք է լինի ձեր ընտրած լեզուն, եթե ձեզ անհրաժեշտ է հարթակին հատուկ վարքագիծ:
