Added formelark

Reviewed-on: #4

_data/ntnu-courses.yml

@@ -18,7 +18,7 @@
     -
       course: tiø4252
       desc: Teknologiledelse, våren 2021.
-      updated: 2021-05-04
+      updated: 2021-05-13
 
 # Høsten 2020
 -

ntnu/21v/tiø4252/tiø4252.md

@@ -0,0 +1,68 @@
+---
+title: TIØ4252
+description: Teknologiledelse, våren 2021
+date: 2021-05-13
+---
+
+
+## Formelark
+
+Formelark i TIØ4252 kan finnes [her][formel].
+
+Kildekoden ligger på [git][git_formel].
+
+[formel]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/formelark/formelark.pdf
+[git_formel]:https://git.glados.no/oyvindskaaden/TIO4252/src/branch/main/formelark/
+
+## Eksamen
+
+Alle filer er tilgjengelig på [git][git].
+
+[git]: https://git.glados.no/oyvindskaaden/TIO4252
+
+Kombinert løsningsforslag for alle eksamener finnes [her][LF_alle].
+
+[LF_alle]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/LF.pdf
+
+| År   | Eksamen | Oppgave       | LF       |
+| :--- | :------ | :------------ | :------- |
+| 2020 | Høst    | [Oppgave][1]  | [LF][2]  |
+| 2020 | Sommer  | [Oppgave][3]  | [LF][4]  |
+| 2020 | Vår     | [Oppgave][5]  | [LF][6]  |
+| 2019 | Høst    | [Oppgave][7]  | [LF][8]  |
+| 2019 | Sommer  | [Oppgave][9]  | [LF][10] |
+| 2018 | Høst    | [Oppgave][11] | [LF][12] |
+| 2018 | Sommer  | [Oppgave][13] | [LF][14] |
+| 2018 | Vår     | [Oppgave][15] | [LF][16] |
+| 2017 | Høst    | [Oppgave][17] | [LF][18] |
+| 2017 | Vår     | [Oppgave][19] | [LF][20] |
+| 2014 | Sommer  | [Oppgave][21] | [LF][22] |
+| 2013 | Sommer  | [Oppgave][23] | [LF][24] |
+{: .table-responsive-lg .table }
+
+[1]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/20H/Eksamen_20H.pdf
+[2]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/20H/Losning_20H.pdf
+[3]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/20S/Eksamen_20S.pdf
+[4]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/20S/Losning_20S.pdf
+[5]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/20V/Eksamen_20V.pdf
+[6]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/20V/Losning_20V.pdf
+[7]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/19H/Eksamen_19H.pdf
+[8]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/19H/Losning_19H.pdf
+[9]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/19S/Eksamen_19S.pdf
+[10]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/19S/Losning_19S.pdf
+[11]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/18H/Eksamen_18H.pdf
+[12]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/18H/Losning_18H.pdf
+[13]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/18S/Eksamen_18S.pdf
+[14]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/18S/Losning_18S.pdf
+[15]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/18V/Eksamen_18V.pdf
+[16]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/18V/Losning_18V.pdf
+[17]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/17H/Eksamen_17H.pdf
+[18]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/17H/Losning_17H.pdf
+[19]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/17V/Eksamen_17V.pdf
+[20]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/17V/Losning_17V.pdf
+[21]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/14S/Eksamen_14S.pdf
+[22]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/14S/Losning_14S.pdf
+[23]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/13S/Eksamen_13S.pdf
+[24]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/13S/Losning_13S.pdf
+
+

ntnu/21v/ttk4145/summary/summary.md

@@ -63,9 +63,9 @@ This is some of the error handling real time programming have.
 * Handling of unexpected errors
 * More threads hanles errors
 * Can not test the conventional way
-  * Can only show extistence of errors
-  * Can not find errors in specification
-  * Can not find race conditions
+    * Can only show extistence of errors
+    * Can not find errors in specification
+    * Can not find race conditions
 
 The fault path is shown under.
 
@@ -103,8 +103,8 @@ To test how the systems responds for a unknown error is to insert a failed accep
 **Dynammic redunancy**
 
 * Relies on detecting the error and recovering
-  * Resend if timeout and not receiving "ack"
-  * Go with default if no messages have been received
+    * Resend if timeout and not receiving "ack"
+    * Go with default if no messages have been received
 * The acceptancetest must be good.
 
 
@@ -128,29 +128,29 @@ Find the failure modes: What could go wrong?
 **Step 3: Handling with redundancy**
 
 * Have multiple copies of the the information
-  * Use only the newest
+    * Use only the newest
 
 #### Example with communication function
 
 **Step 1: Failure modes**
 
 * Message
-  * Lost
-  * Delayed
-  * Corrupted
-  * Duplicated
-  * Wrong recipient
+    * Lost
+    * Delayed
+    * Corrupted
+    * Duplicated
+    * Wrong recipient
 
 **Step 2: Detection, Merging of errormodes and error injection**
 
 * Adding information to message
-  * Checksum
-  * Session ID
-  * Sequence number
+    * Checksum
+    * Session ID
+    * Sequence number
 * Adding "ack" on well recieved messages
 * All errors will be treaded as "Lost message"
 * Injection
-  * Occasionally throw away some messages
+    * Occasionally throw away some messages
 
 **Step 3: Handling with redundancy**
 
@@ -179,7 +179,7 @@ There are three solutions:
     * Store a checkpoint
     * Do the "side effects"
 2. Process pairs
-    * Crash and let an another process take over
+        * Crash and let an another process take over
 3. Presistent processes
 
 
@@ -198,3 +198,179 @@ A transaction is a design framework for Damage Confinement and Error Recovery.
 * **C**oncistency: Leaves the system in a consistent state when finished
 * **I**solation: Errors does not spread
 * **D**urability: Results are not lost
+
+### Atomic Actions
+
+**Resumption vs. Termination mode**
+* If we continue where we were (e.g. after the interrupt) --> *Resumption*
+* If we continue somewhere else (i.e. terminating what we where doing) --> Termination
+
+**Async Notification (AN) = Low level thread interaction**
+* Async event handling. ("Signals") (resumption)
+    * Modeled after a HW interrupt
+    * Can be sent to the correct thread
+    * Can be handled, ignored, blocked --> The domain can be controlled.
+    * Often lead to polling
+        * Could rather skip the signal and poll a status variable or a message queue
+        * Useless
+* ATC --> Async transfer of Control (termination)
+    * Canceling threads
+    * setjmpt/longjmp could convert signals to ATC (not really, but still)
+    * ADA: a strictured mechanism for ATV is integraded with the selected statement
+    * RT Java: A structured mechanism for ATC is integraded with the exception-handling mechanism
+
+#### Cancelling threads
+
+**Yes, killing threads is ATC!**
+
+* Can make termination model by letting domain be a thread
+    * "Create a `doWork` thread, and kill it if the action fails"
+* Ca still control domain by disabling "cancelstate"
+
+**But, but, but: It leaves ut in undifined state!?**
+* Not if we have...
+    * Full control over changed state (like logs or recovery points) or some other way of recovering well.
+    * A lock manager that can unlock on behalf of killed thread
+    * Some control of where we were killed (like nok in the middle of a lock manager or log call)
+* An this is what we have!
+
+
+## Shared variable synchronization
+
+### Non-Preemptive scheduling
+
+Controlling a pump filling a tank.
+
+**Spec:**
+* Every second: measure the water level of the tank and generate the reference to the pump
+* 10 times a second: Set the power of the pump motor
+* Do some GUI: let the human control the process
+
+#### A trivial solution: "Cyclic Exectutive"
+
+{% highlight c %}
+oldTime = now();
+i = 0;
+while(true) {
+    i = i + 1;
+    if (i % 10 == 0) {
+        i = 0;
+        calculatePumpReference();
+    }
+    controlPump();
+    do {
+        handleUserEvent();
+    } while(now() < oldTime + 0.1);
+    oldTime = oldTime + 0.1;
+}
+{% endhighlight %}
+
+**Drawbacks**
+
+* OK tasks?
+* Timing hard to tune (what if pump sampling should be $\pi$/10?)
+* Overload (what if `calucaltePumpReference` uses more than 1/10 seconds?)
+* How to add new tasks? (Everything is coupled)
+* Waste of time in the do-loop?
+* What is priority of `handleUserEvents`?
+* How are erros, exceptions, alarms etc. handled?
+
+#### Better soulution with Non-preemptive scheduler
+
+* *3 taskts* administered by a scheduler
+* The scheduler takes care of who runs and timing
+* Scheduler often inculuded in OSes
+* Introducing priorities
+
+{% highlight c %}
+/**
+    * scheduler_registerThread(function, time, priority)
+    * Higher priority numer means higher priority in scheduler
+    */
+main() {
+        scheduler_registrerThread(controlPump, 0.1, 3);
+        scheduler_registrerThread(calculatePumpReference, 1, 2);
+        scheduler_registrerThread(handleUserEvents, 0.2, 1);
+        scheduler_mainLoop();
+}
+{% endhighlight %}
+
+**Some notes on priorities**
+* Priority is generally not important; rather, the main rule is to give higher priority to shorter-deadline tasks. 
+    * This allows tasks to reach its deadlines.
+* ... but this is not always the case - if e.g. the tasks are cooperating
+* We still handle overload badly
+* And: What connection between deadline and priority to start with?
+    * Is this a good dependency seen from a code quality perspective?
+
+### Pros and cons of nonpreemptive scheduling
+
+| **Pros**                                       | **Cons**                                                                   |
+| :--------------------------------------------- | :------------------------------------------------------------------------- |
+| Simple, intuitive, predictable                 | C macro hell                                                               |
+| No kernel                                      | Threads must cooperate <-- a form of dependency breaking module boundaries |
+| Fast switching times                           | Heavy threads must be divided                                              |
+| Some elegant sunchronization patterns possible | Can we handle blocking of library functions?                               |
+|                                                | Unrobust to errors                                                         |
+|                                                | Unrobust to (heavy) error handling                                         |
+|                                                | Hard to tune at end of project                                             |
+{: .table-responsive-lg .table }
+
+
+
+### Preemptive Kernel
+
+* Preemption, thread objects and the timer interrupt
+* Enabling synchronization: Busy waiting, tes-and-set, disabling the timer interrupt
+* Blocking and suspend & resume
+* An API for synchronization? Semaphores!
+
+
+#### Preemption
+
+* Make a handler for a timer interrupt
+* Store all registers (including IP & SP) in a "thread object"
+* Organize queue of processes (Round Robin e.g. - a collection of thread objects?)
+* Can synchronize by: while(!ready); (busy wating, "spin locks")
+
+**Bad solution**
+
+{% highlight c%}
+while(lock==1) {}
+lock = 1;
+    // We may run
+lock = 0;
+{% endhighlight %}
+
+**Better solution**
+
+{% highlight c%}
+void t1() {
+    flag1 = 1;  // Declare my intention
+    turn  = 2;  // But try to be polite
+    while(flag2 == 1 && turn == 2) {}
+    // We may run
+    flag1 = 0;
+}
+{% endhighlight %}
+
+##### Looking more closely at the arsenal
+
+**How can we make basic synchronization under preemption?**
+
+* Spin locks (wasting time and cpu)
+* Test&Set (swap) assembly instruction (atomic, but not obvious)
+* Disable interrupt (steals control from OS/scheduler)
+
+**But**
+* If we disable the timer interrupt we don not have preemption any more
+* And... Are these good abstractions in the application programmer domain?
+
+#### Blocked threads
+
+**Let us introduce another queue; the collection of threads not running, waiting for something**
+
+* Fixes the bad performance of spin locks. Is conceptually better.
+* "Suspend" moves a thread object from "run" queue to "blocked" queue
+* "Resume" moves it back.
+