Software engineeringում կան bug եր, որոնք գտնելը հեշտ չի, իսկ Race Condition ները հենց դրանցից են։ Դրանք սովորաբար առաջանում են concurrent համակարգերում, երբ մի քանի գործողություններ միաժամանակ են կատարվում ու արդյունքը կախված ա timing ից։ Ամենավատն էն ա, որ նման bug երը միշտ չեն reproducе լինում ու կարող են երկար ժամանակ աննկատ մնալ, մինչև prod ում լուրջ խնդիր առաջացնեն։

Դրա համար Race condition ները հասկանալը կարևոր ա հատկապես էն developerneri համար, ովքեր աշխատում են multi threaded, distributed կամ asynchronous համակարգերի հետ։


Real Impactner

Amazon Web ը մի անգամ 12+ ժամանոց outage ունեցավ ու դրա ընթացքում Internet ի բավական մեծ հատված էլ տուժեց , Amazon ի postmortemի համաձայն խնդիրը կապված էր իրենց automated DNS management systemի ushacman het. DNS system ը ուներ երկու հիմնական component DNS Planner որը հետևում էր load balancer ների վիճակին ու նոր DNS plans էր ստեղծում ու DNS Enactor որը էդ plans ը կիրառում էր Amazon Route 53 ի միջոցով Խնդիրը առաջացավ Race Condition ի պատճառով

Մի Enactor ը բավական ուշանում էր բայց Planner ը meanwhile շարունակում էր նոր plan ստեղծել. Մյուս Enactor ը սկսեց կիրառել նոր plan երը ու cleanup անել հենց էն պահին երբ առաջին Enactor ը վերջապես ավարտեց իր հին run ը. Cleanup ը սխալմամբ հին planը համարեց stale ու ջնջեց այն. Դրա արդյունքում regional endpoint ի բոլոր IP address ները վերացան ու system ը մտավ inconsistent state. Էդ պահից հետո ոչ մի Enactor այլևս չէր կարողանում ավտոմատ DNS updates անել


Ինչ է Race Condition


Race Condition ը basically առաջանում ա էն ժամանակ, երբ ծրագրի behavior ը կախված ա մի քանի thread, process կամ operation ների timing ից, «Race»-ը հենց էդտեղից ա գալիս, որովհետև տարբեր execution path եր մրցում են նույն shared resource ին access անելու ու փոխելու համար, ու վերջնական արդյունքը կախված ա լինում նրանից, թե ով կհասնի առաջինը, Հիմնական խնդիրը առաջանում ա, երբ երկու կամ ավելի գործողություններ միաժամանակ փորձում են կարդալ ու փոխել նույն data ն, բայց դրանց միջև ճիշտ synchronization չկա. Քանի որ thread երի timing ը միշտ կանխատեսելի չի ու դրա վրա ազդում ա OS scheduler ը, նույն code ը նույն input ներով տարբեր run երի ժամանակ կարող ա լրիվ տարբեր արդյունք տալ

Օրինակ վերցնենք մի պարզ banking scenario, որտեղ երկու thread միաժամանակ փորձում են $100 balance ունեցող account ից գումար հանել

ա : Read balance ($100)
բ : Read balance ($100)
ա : Subtract $60, write $40
բ : Subtract $50, write $50


Sեսակները


Read-Modify-Write races ամենատարածվածներից են։ Էստեղ մի քանի thread նույն value ն կարդում են, մի բան հաշվում ու հետո նորից գրում։ Եթե proper locking կամ atomic operation չկա, thread երը կարող են իրար update ները overwrite անել ու տվյալ կորի

Check-Then-Act races լինում են երբ system-ը սկզբում ստուգում ա ինչ-որ condition ու հետո դրա հիման վրա գործողություն անում։ Բայց էդ երկու քայլերի արանքում ուրիշ thread-ը կարող ա փոխել վիճակը ու unexpected behavior առաջանա

TOCTOU (Time of Check to Time of Use) ը Check Then Act ի ավելի security-critical տարբերակն ա։ System ը մի բան ստուգում ա, հետո օգտագործում՝ մտածելով որ էդ ընթացքում ոչինչ չի փոխվել։ Harcakvoxy ը կարող ա հենց էդ փոքր ժամանակահատվածը օգտագործել ու security check ը շրջանցել

Data races ը լինում ա երբ մի քանի thread նույն memory location ին access են անում առանց proper synchronization ի ու դրանցից գոնե մեկը write ա անում։ Սա կարող ա բերել crash ի, memory corruption-ի կամ նույնիսկ vulnerability ի


Ինչի են Race Condition ները Critical

Race Condition ները վտանգավոր են հիմնականում նրա համար, որ շատ դժվար են reproduce լինում։ Կարող ա հազարավոր անգամ ամեն ինչ նորմալ աշխատի ու մի կոնկրետ timing ի դեպքում հանկարծ bug ը trigger լինի. Դրանք կարող են նաև բերել data corruption ի։ Օրինակ կարող են սխալ balance ներ, duplicate transaction ներ կամ կորած payment ներ առաջանալ

Security ի տեսանկյունից էլ Race Condition ները լուրջ խնդիր են։ TOCTOU vuln ներով հնարավոր ա bypass անել security check եր, privilege escalation անել կամ access ստանալ unauthorized resource ների. Մյուս խնդիրն էլ scalability ն ա։ App ը կարող ա մի քանի user ի դեպքում լրիվ նորմալ աշխատել, բայց հազարավոր concurrent user ների ժամանակ հանկարծ սկսի կոտրվել

Ու վերջում testing ն էլ ա բարդանում։ Race Condition ը կախված ա գործողությունների ճիշտ ժամանակավորումից, դրա համար սովորական թեստերը միշտ չեն կարողանում բռնել։ Կարա development ի ժամանակ ամեն ինչ նորմալ աշխատի, բայց prod ում, երբ միաժամանակ ավելի շատ գործողություններ են կատարվում, հանկարծ bug ը հայտնվի lol