Betriebssysteme/hw8/simu1/ANSWERS.md

hw8 - Simulation 1 - Antworten

1. Helgrind markiert die richtigen Stellen im Code:

   ==1930== Possible data race during write of size 4 at 0x60207C by thread #1
   ==1930== Locks held: none
   ==1930==    at 0x400C9A: main (main-race.c:15)
   ==1930==
   ==1930== This conflicts with a previous write of size 4 by thread #2
   ==1930== Locks held: none
   ==1930==    at 0x400C5A: worker (main-race.c:8)
   

   Weiterhin erhält man die Information über den Lock (hier none), die Art des Problems (Possible data race) und die Größe der Daten, die geschrieben werden.

2. Codekorrektur

   1. Wenn ich eine der Zeilen lösche (bzw. auskommentiere), meldet helgrind keinen Fehler mehr (auch nicht für die zweite betreffende Zeile).

   2. Wenn man nur bei einer Variable den Lock setzt, erkennt helgrind den Fehler:

      ==18432== Possible data race during write of size 4 at 0x602084 by thread #1
      ==18432== Locks held: none
      ==18432==    at 0x400CB2: main (main-race.c:18)
      ==18432==
      ==18432== This conflicts with a previous write of size 4 by thread #2
      ==18432== Locks held: 1, at address 0x6020A0
      ==18432==    at 0x400C68: worker (main-race.c:10)
      

   3. Wenn man bei beiden Variablen einen Lock setzt, findet helgrind wieder keine Fehler.

3. Vermutlich ist der Fehler, dass Thread 1 einen Lock auf v1 setzt, Thread 2 einen Lock auf v2, und anschließend warten beide Threads, bis der jeweils andere diesen Lock wieder freigibt. Auf der Labshell läuft das Programm. Dieser Deadlock tritt nur auf, wenn Thread 1 und Thread 2 wirklich absolut parallel laufen.

4. Helgrind gibt mir viele Informationen zur Lockreihenfolge. Es sagt, dass es durch das Festlegen des ersten Locks eine feste Reihenfolge gibt, in der neue Locks gesetzt werden müssen. Zusätzlich bekomme ich die Information, wo die Reihenfolge festgelegt wird und wo sie nicht eingehalten wird.

5. Blah

   1.

   2.

   3.

   4.

6.

1. Blah

   1.

   2.

2. Blah

   1.

   2.

9.