Merge branch 'hw8' of https://github.com/themultiplexer/bsys-ws17-grp11 into hw8

hw8/simu2/ANSWERS.md

@@ -0,0 +1,33 @@
+# hw8 - Simulation 2 - Antworten
+
+0. Beim Erstellen wird ein Pointer übergeben, welcher dann in einen `int` gecastet werden soll. Dies funktioniert jedoch nicht, da die Größe unterschiedlich ist. Um dies zu beheben, castet man den Pointer einfach zu einem `long int`, dann stimmt die Größe.
+
+### `main-two-cvs-while.c`
+
+1. Wenn der Buffer größer wird, ändert sich nichts am Code. Die Zahl der produzierten Werte ist jedoch linear zu den Codezeilen. Das Programm ist also nicht abhängig von der Buffergröße.
+
+2. Der Producer wird (sofern die Zahl der produzierten Werte größer ist als die Größe des Buffers) den Buffer komplett füllen und der Consumer dann immer ein Item konsumieren. Im Gegensatz dazu hat der Consumer im ersten Test immer sofort konsumiert, d.h. der Buffer läuft nie voll.
+
+3. Auf der Labshell ist das Verhalten unterschiedlich zu dem auf beispielsweise einem Laptop: Der Consumer braucht auf der Labshell nicht so lange wie auf einem Laptop, da die Laufzeit offensichtlich systemabhängig ist.
+
+4. Da der Producer 10 Werte produziert, wird 10 mal für je eine Sekunde gewartet. Die zu erwartende Laufzeit liegt also über 10 Sekunden.
+
+5. Da der Producer immer noch 10 Werte produziert und dies nicht von der Größe des Buffers abhängig ist, ist die Laufzeit mit einer Buffergröße von 3 also gleich groß wie bei **4**.
+
+6. In diesem Fall werden die produzierten Werte abwechselnd von den einzelnen Consumern konsumiert. Diese warten anschließend für je eine Sekunde. Der Producer produziert 10 Werte, die auf drei Consumer aufgeteilt werden, also `C0: 4, C1: 3, C2: 3`. `C0` wartet 4 mal, also muss die Laufzeit länger als 4 Sekunden dauern.
+
+7. Wie bei **5** ist die Laufzeit hier nicht von der Größe des Buffers abhängig, da die Werte direkt aus dem Buffer konsumiert werden und dieser somit nie voll wird. Die zu erwartende Laufzeit ist also dieselbe wie bei **6**.
+
+### `main-one-cv-while.c`
+
+1. Nein, denn mit einer Condition-Variable und einer while-Schleife können nur Fehler auftreten, wenn ein zweiter Consumer geweckt wird. Da dieser hier jedoch nicht existiert, treten keine Fehler im Programm auf.
+
+2. 
+
+### `main-two-cvs-if.c`
+
+1.
+
+### `main-two-cvs-while-extra-unlock.c`
+
+1.

hw8/simu2/main-one-cv-while.c

@@ -34,7 +34,7 @@ int do_get() {
 }
 
 void *producer(void *arg) {
-    int id = (int) arg;
+    long int id = (long int) arg;
     // make sure each producer produces unique values
     int base = id * loops; 
     int i;
@@ -51,7 +51,7 @@ void *producer(void *arg) {
 }
                                                                                
 void *consumer(void *arg) {
-    int id = (int) arg;
+    long int id = (long int) arg;
     int tmp = 0;
     int consumed_count = 0;
     while (tmp != END_OF_STREAM) { c0;

hw8/simu2/main-two-cvs-if.c

@@ -34,7 +34,7 @@ int do_get() {
 }
 
 void *producer(void *arg) {
-    int id = (int) arg;
+    long int id = (long int) arg;
     // make sure each producer produces unique values
     int base = id * loops; 
     int i;
@@ -51,7 +51,7 @@ void *producer(void *arg) {
 }
                                                                                
 void *consumer(void *arg) {
-    int id = (int) arg;
+    long int id = (long int) arg;
     int tmp = 0;
     int consumed_count = 0;
     while (tmp != END_OF_STREAM) { c0;

hw8/simu2/main-two-cvs-while-extra-unlock.c

@@ -35,7 +35,7 @@ int do_get() {
 }
 
 void *producer(void *arg) {
-    int id = (int) arg;
+    long int id = (long int) arg;
     // make sure each producer produces unique values
     int base = id * loops; 
     int i;
@@ -54,7 +54,7 @@ void *producer(void *arg) {
 }
                                                                                
 void *consumer(void *arg) {
-    int id = (int) arg;
+    long int id = (long int) arg;
     int tmp = 0;
     int consumed_count = 0;
     while (tmp != END_OF_STREAM) { c0;

hw8/simu2/main-two-cvs-while.c

@@ -36,7 +36,7 @@ int do_get() {
 }
 
 void *producer(void *arg) {
-    int id = (int) arg;
+    long int id = (long int) arg;
     // make sure each producer produces unique values
     int base = id * loops; 
     int i;
@@ -53,7 +53,7 @@ void *producer(void *arg) {
 }
                                                                                
 void *consumer(void *arg) {
-    int id = (int) arg;
+    long int id = (long int) arg;
     int tmp = 0;
     int consumed_count = 0;
     while (tmp != END_OF_STREAM) { c0;

hw8/task1/ANSWERS.md

@@ -0,0 +1,35 @@
+# Proof of Work 2.0
+
+
+#### 1. Wie ist die Ausgabe von time zu interpretieren, wenn mehrere Threads laufen?
+
+Die user-time ist immer deutlich höher als die real-time.
+Das heißt, dass die Threads nicht nebenläufig, sondern parallel laufen.
+
+#### 2. Welche unterschiedlichen Ergebnisse erhalten Sie bei der Option timings? Wie stehen diese im Zusammenhang mit den Ergebnissen von time?
+
+
+Die Option `timings` variiert stark von den Ergebnissen von **time**. Das unix-Kommando time bezieht die Ausführungszeit des gesamten Codes mt ein.
+Also auch Aufrufe von *sys-info* oder zum Beispiel das Parsen der Argumente, welches *clap* durchführt.
+
+#### 3. Welche quantitativen Auswirkungen hat die Synchronisierung (Warum)? Welche Auswirkungen haben Ihre zusätzlichen Parameter?
+
+#### 4. Wie variieren -s und -w die Messungen?
+
+Mit `-s` und `-v`:
+  ```text
+  Sum Loops in Producers:       66106870
+  Sum Duration in Producers:    25s / 25160ms / 25160747us
+  ```
+
+Ohne `-s` und `-v`:
+
+Wartet der Consumer bis jeder Thread eine *Solution* gefunden hat. Dies ist sehr deutlich an den Loop-anzahl und der Zeit erkennbar.
+  ```text
+  Sum Loops in Producers:       147581082
+  Sum Duration in Producers:    37s / 37244ms / 37244327us
+  ```
+ 
+#### 5. Welche sonstigen Arten der Synchronisierung bieten sich für die Problemstellung "Lösung gefunden (-s)" an? Was sind deren Vor- und Nachteile gegenüber Ihrer gewählten Lösung?
+
+Man könnte anstatt dem Arc und dem AtomicBool im Consumer aktiv alle Threads töten, sobald eine Lösung gefunden wurde.