Add the rest of university notes

docs/lectures/osc/06_concurrency3.md

@@ -43,7 +43,7 @@ The process/thread that acquires the lock must **release the lock** - in contras
 | Context switches can be **avoided**.                         | Calls to `acquire()` result in **busy waiting**. Shocking performance on single CPU systems. |
 | Efficient on multi-core systems when locks are **held for a short time**. | A thread can waste it's entire time slice busy waiting.      |
 
-![img](/lectures/osc/assets/S.png)
+![img](assets/S.png)
 
 
 
@@ -143,7 +143,7 @@ Semaphores within the **same process** can be declared as **global variables** o
 > * `sem_wait()` - decrements the value of the semaphore.
 > * `sem_post()` - increments the values of the semaphore.
 
-![img](/lectures/osc/assets/t.png)
+![img](assets/t.png)
 
 Synchronising code does result in a **performance penalty**
 
@@ -198,7 +198,7 @@ The simplest version of this problem has **one producer**, **one consumer** and
   * `sync` **synchronises** access to the **buffer** (counter) which is initialised to 1.
   * `delay_consumer` ensures that the **consumer** goes to **sleep** when there are no items available, initialised to 0.
 
-![img](/lectures/osc/assets/U.png)
+![img](assets/U.png)
 
 It is obvious that any manipulations of count will have to be **synchronised**.
 
@@ -231,4 +231,4 @@ A different variant of the problem has `n` consumers and `m` producers and a fix
 
 The `empty` and `full` are **counting semaphores** and represent **resources**.
 
-![img](/lectures/osc/assets/V.png)
+![img](assets/V.png)