Jag analyserar 3a's mutexhantering först.

3a har alla faktorer som krävs för att en deadlock ska kunna förekomma:
Ej delbara resurser, cyklisk väntan och det att de ej låser upp resurserna om låsningen misslyckas.

3a låser enbart upp resurserna om de är färdiga med sin kritiska sektion, vilket de med stor sannolikhet ej kommer kunna göra eftersom att trådfunktion ett låser m1, sover och där kanske schedulern bestämmer sig för att byta till tråd 2. Vid det tillfället låser trådfunktion 2 m2 och sover en stund och där kanske schedulern bestämmer sig för att byta till tråd 1 igen, men nu har tråd 2 låst m2 som trådfunktion 1 nu ville låsa kommer de gå fram och tillbaka för att försöka låsa de nu deadlocked resurserna.

Detta är varför det är en stor chans för 3a att enbart skriva ut nollor.


3b däremot använder en funktion som heter pthread_mutex_trylock som kommer låsa den kallande tråden om resursen den försöker låsa redan är låst. Därefter har båda 3b's trådfunktioner en if-sats som ser till att rätt mutex unlockas om trylock ej lyckas så att deadlock inte förekommer när nästa tråd ska använda sitt pthread_mutex_trylock-anrop.

På grund av de testerna och upplåsningarna av resurser som sker på 3b's trådfunktioner kommer deadlock ej ske och programmet fungerar som tänkt.
