Programmet uppg3a.c har två trådar som delar på samma två resurser. Enda skillnaden här 
är att tråd1 låser resurs1 först, och tråd2 låser resurs2 först. Båda trådar väntar en 
sekund innan den låser den andra resursen den vill använda. Eftersom varje tråd endast 
väntar 1-3 sekunder innan den börjar låsa resurser, finns en stor sannolikhet de väntar 
lika länge innan de börjar låsa resurser. Då kan hända att tråd hinner låsa sin första 
resurs, och nästa tråd hinner låsa sin första resurs innan den första tråden låst den 
(vilket ska ske efter en sekunds väntan). I det fallet skapas en form av cyklisk väntan 
då varje tråd blir blockerad av den andra och ingen tråd kommer att kunna sätta värdet 
1 eller 2 (som det står i manualsidan för mutex_lock, kommer en en anropande tråd att 
blockeras om en mutex är låst, ända tills den blir tillgänglig. Detta händer när man 
använder unlock på samma mutex). Det finns inget i programmet som kan ta bort denna låsning.

I programmet uppg3b.c hanteras detta lite annorlunda. De båda trådarna försöker 
fortfarande låsa resurser i samma ordning, men de väntar inte innan de försöker låsa
den andra resursen. Detta löser dock inte hela problemet, eftersom trådarna arbetar 
parallellt med varandra och därför kan låsa sig av ren slump. Denna möjlighet tas bort
helt genom att använda funktionen trylock som gör nästan samma sak som lock, med en liten 
skillnad. Enligt manualsidan gör en trylock samma sak som lock, men återvänder med värdet 
noll om den märker att den försökt låsa en mutex som redan var låst. När programmet gör 
detta finns ingen chans att varje tråd skulle låsa endast en resurs och sedan blockeras, 
eftersom den inte finns något anrop efter första låsningen som kan blockera. Om de skulle
låsa endast en resurs var, skulle en av trådarna märka det och låsa upp sin resurs åt den 
andra. Därav blir det aldrig någon låsning.
