Arhitectura Sistemelor de Calcul (curs)

2026-11-09T20:27:08Z

OS Lab 5 - Threads. Mutexes

2026-11-06T14:04:59Z

Pagină nouă: In the last lab, we created new processes with [https://man7.org/linux/man-pages/man2/fork.2.html <code>fork(2)</code>], and each of them had a si...

Pagină nouă

In [[OS_Lab_4_-_Processes._Signals|the last lab]], we created new processes with [https://man7.org/linux/man-pages/man2/fork.2.html <code>fork(2)</code>], and each of them had a single task. In this lab, we will give one process several tasks, its '''threads''', which share its memory. We will create them with [https://man7.org/linux/man-pages/man3/pthread_create.3.html <code>pthread_create(3)</code>], wait for them with [https://man7.org/linux/man-pages/man3/pthread_join.3.html <code>pthread_join(3)</code>], and protect the data they share with '''mutexes'''. We will also see what these functions ask of the kernel: [https://man7.org/linux/man-pages/man2/clone.2.html <code>clone(2)</code>] and [https://man7.org/linux/man-pages/man2/futex.2.html <code>futex(2)</code>]. As an application, we will simulate a small bank.

== Learning objectives ==

By the end of this lab you should be able to:

# create threads with [https://man7.org/linux/man-pages/man3/pthread_create.3.html <code>pthread_create(3)</code>], and wait for them with [https://man7.org/linux/man-pages/man3/pthread_join.3.html <code>pthread_join(3)</code>];
# explain which [https://man7.org/linux/man-pages/man2/clone.2.html <code>clone(2)</code>] flags make a new task a thread of the same process;
# recognize a '''race''' on shared data, and fix it with a mutex;
# explain how a mutex uses [https://man7.org/linux/man-pages/man2/futex.2.html <code>futex(2)</code>], and why an uncontended lock needs no system call;
# recognize a '''deadlock''', and avoid it by always locking in the same order.

== Threads ==

A '''thread''' is a task which shares memory with other tasks in a task group (process). All the threads of a process run the same program and see the same global variables and heap, but each has its own registers and its own stack, so each can be at a different point of the program, in a different function.

On Linux, threads are created and managed with the ''POSIX threads'' (''pthreads'') functions, which are part of ''glibc''.

=== pthread_create(3) ===

<syntaxhighlight lang="c">
// In: <pthread.h>
int pthread_create(pthread_t *thread, const pthread_attr_t *attr,
void *(*start_routine)(void *), void *arg);
</syntaxhighlight>

{| class="wikitable"
! Parameter !! Description
|-
| <code>thread</code> || Where to store the ID of the new thread, used later to wait for it
|-
| <code>attr</code> || Options, such as the size of the stack, or <code>nullptr</code> for the defaults
|-
| <code>start_routine</code> || The function the new thread runs. When it returns, the thread ends
|-
| <code>arg</code> || The argument passed to <code>start_routine</code>
|}

The new thread starts running <code>start_routine(arg)</code>, while the thread that created it continues after [https://man7.org/linux/man-pages/man3/pthread_create.3.html <code>pthread_create(3)</code>]. Both <code>arg</code> and the return value of <code>start_routine</code> are <code>void *</code>, so a thread can be given, and can give back, a pointer to anything.

<div class="regula">'''Note:''' The pthreads functions do '''not''' set <code>errno</code>. They return 0 on success, or the error number itself (for example, <code>EAGAIN</code>) on error. The examples below use a <code>print_error()</code> which takes that number as a parameter.</div>

The following program starts three threads, gives each one its own number, and each of them prints its PID and its '''TID''' (''thread ID''), the ID of the task:

<syntaxhighlight lang="c" line>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <pthread.h>
#include <unistd.h>

#define N_THREADS 3

static void print_error(const char *what, int err)
{
char msg[256];
snprintf(msg, sizeof msg, "%s: %s\n", what, strerror(err));
write(STDERR_FILENO, msg, strlen(msg));
}

static void *worker(void *arg)
{
int id = *(int *) arg;
char msg[256];
snprintf(msg, sizeof msg, "thread %d: PID %d, TID %d\n", id, getpid(), gettid());
write(STDOUT_FILENO, msg, strlen(msg));
return nullptr;
}

int main(void)
{
pthread_t threads[N_THREADS];
int ids[N_THREADS];

for (int i = 0; i < N_THREADS; i++) {
ids[i] = i;
int err = pthread_create(&threads[i], nullptr, worker, &ids[i]);
if (err != 0) {
print_error("pthread_create", err);
return EXIT_FAILURE;
}
}

for (int i = 0; i < N_THREADS; i++) {
pthread_join(threads[i], nullptr);
}

char msg[256];
snprintf(msg, sizeof msg, "main: PID %d, TID %d\n", getpid(), gettid());
write(STDOUT_FILENO, msg, strlen(msg));
return EXIT_SUCCESS;
}
</syntaxhighlight>

<syntaxhighlight lang="bash">
$ ./build/debug/app
thread 0: PID 4307, TID 4308
thread 1: PID 4307, TID 4309
thread 2: PID 4307, TID 4310
main: PID 4307, TID 4307
</syntaxhighlight>

All the threads have the same PID: they are one process. Each has its own TID, and the first thread of the process, the one which runs <code>main()</code>, has a TID equal to the PID. The three lines may come in any order: the threads run independently.

<div class="regula">'''Note:''' Each thread is given a pointer to its own element of <code>ids</code>. Passing <code>&i</code> instead would be a bug: all the threads would get a pointer to the same variable, which the loop keeps changing, leading to a race condition on access.</div>

=== pthread_join(3) ===

<syntaxhighlight lang="c">
// In: <pthread.h>
int pthread_join(pthread_t thread, void **retval);
</syntaxhighlight>

[https://man7.org/linux/man-pages/man3/pthread_join.3.html <code>pthread_join(3)</code>] waits for a thread to end, the way [https://man7.org/linux/man-pages/man2/waitpid.2.html <code>waitpid(2)</code>] waits for a child process. If <code>retval</code> is not <code>nullptr</code>, it stores there the value returned by the thread's function.

A simpler way to get results back is to give each thread a structure, with both its input and a place for its output. The following program adds up the numbers from 0 to 99,999,999 with four threads, each adding a quarter of them:

<syntaxhighlight lang="c" line>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <pthread.h>
#include <unistd.h>

#define N_THREADS 4
#define N 100000000

static void print_error(const char *what, int err)
{
char msg[256];
snprintf(msg, sizeof msg, "%s: %s\n", what, strerror(err));
write(STDERR_FILENO, msg, strlen(msg));
}

// What one thread works on: its input, and a place for its result.
struct part {
long from, to; // Add the numbers in [from, to)
long sum;
};

static void *add_range(void *arg)
{
struct part *p = arg;
p->sum = 0;
for (long i = p->from; i < p->to; i++) {
p->sum += i;
}
return nullptr;
}

int main(void)
{
pthread_t threads[N_THREADS];
struct part parts[N_THREADS];

for (int i = 0; i < N_THREADS; i++) {
parts[i].from = (long) N / N_THREADS * i;
parts[i].to = (long) N / N_THREADS * (i + 1);
int err = pthread_create(&threads[i], nullptr, add_range, &parts[i]);
if (err != 0) {
print_error("pthread_create", err);
return EXIT_FAILURE;
}
}

long sum = 0;
for (int i = 0; i < N_THREADS; i++) {
pthread_join(threads[i], nullptr);
sum += parts[i].sum;
}

char msg[256];
snprintf(msg, sizeof msg, "sum of 0..%d: %ld\n", N - 1, sum);
write(STDOUT_FILENO, msg, strlen(msg));
return EXIT_SUCCESS;
}
</syntaxhighlight>

<syntaxhighlight lang="bash">
$ ./build/debug/app
sum of 0..99999999: 4999999950000000
</syntaxhighlight>

Each thread writes only to its own <code>struct part</code>, and <code>main()</code> reads it only after [https://man7.org/linux/man-pages/man3/pthread_join.3.html <code>pthread_join(3)</code>], when the thread has ended. The threads never touch the same data at the same time, so nothing more is needed in this case.

<div class="regula">'''Note:''' Returning from <code>main()</code>, or calling [https://man7.org/linux/man-pages/man3/exit.3.html <code>exit(3)</code>] from any thread, ends the '''whole process''', with all its threads (it uses the <code>exit_group</code> system call). To end only the calling thread, return from its function, or call [https://man7.org/linux/man-pages/man3/pthread_exit.3.html <code>pthread_exit(3)</code>]. This is why <code>main()</code> must join the threads before it returns.</div>

=== Under the hood: clone(2) ===

[https://man7.org/linux/man-pages/man3/pthread_create.3.html <code>pthread_create(3)</code>] creates the new task with the [https://man7.org/linux/man-pages/man2/clone.2.html <code>clone(2)</code>] system call, the same one [https://man7.org/linux/man-pages/man2/fork.2.html <code>fork(2)</code>] uses. The difference is in the flags, which say what the new task shares with the one that created it:

{| class="wikitable"
! Flag !! The new task shares
|-
| <code>CLONE_VM</code> || The memory: the code, the global variables, the heap, and the stacks of the other threads
|-
| <code>CLONE_FILES</code> || The file descriptor table: a file opened by one thread can be used by all of them
|-
| <code>CLONE_SIGHAND</code> || The signal handlers
|-
| <code>CLONE_THREAD</code> || The process: the new task gets a new TID, but the same PID, and is not a child to be waited for with [https://man7.org/linux/man-pages/man2/waitpid.2.html <code>waitpid(2)</code>]
|}

[https://man7.org/linux/man-pages/man2/fork.2.html <code>fork(2)</code>] calls [https://man7.org/linux/man-pages/man2/clone.2.html <code>clone(2)</code>] with none of these, so the child gets a copy of everything instead. Since the memory is shared, the new thread cannot use the stack of the thread which created it. Before calling [https://man7.org/linux/man-pages/man2/clone.2.html <code>clone(2)</code>], glibc allocates a new stack (8 MiB by default) with [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>], and gives its address to [https://man7.org/linux/man-pages/man2/clone.2.html <code>clone(2)</code>].

[[File:OS_Lab_5_-_threads.png|center|thumb|500px|One process with three threads. They share all the memory of the process, but each one has its own registers, and its own stack, which glibc maps with [https://man7.org/linux/man-pages/man2/mmap.2.html <code>mmap(2)</code>] before calling [https://man7.org/linux/man-pages/man2/clone.2.html <code>clone(2)</code>].]]

== Races ==

Since threads share their memory, two threads can change the same variable at the same time. The following program starts two threads, and each of them increments a global counter one million times:

<syntaxhighlight lang="c" line>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <pthread.h>
#include <unistd.h>

#define N 1000000

static long counter = 0;

static void *increment(void *arg)
{
(void) arg;
for (int i = 0; i < N; i++) {
counter++;
}
return nullptr;
}

int main(void)
{
pthread_t a, b;
pthread_create(&a, nullptr, increment, nullptr);
pthread_create(&b, nullptr, increment, nullptr);
pthread_join(a, nullptr);
pthread_join(b, nullptr);

char msg[256];
snprintf(msg, sizeof msg, "counter = %ld (expected %d)\n", counter, 2 * N);
write(STDOUT_FILENO, msg, strlen(msg));
return EXIT_SUCCESS;
}
</syntaxhighlight>

<syntaxhighlight lang="bash">
$ ./build/debug/app
counter = 1018661 (expected 2000000)
$ ./build/debug/app
counter = 1008721 (expected 2000000)
</syntaxhighlight>

The result is wrong, and different every time. <code>counter++</code> looks like a single operation, but the processor does it in three steps: '''load''' the value from memory into a register, '''add''' 1 to the register, and '''store''' the register back to memory. When two threads do these steps at the same time, they can both load the same value, and one of the increments is lost.

[[File:OS_Lab_5_-_lost_update.png|center|thumb|600px|<code>counter++</code> is three steps. If two threads interleave them, both load 5 and both store 6: one of the two increments is lost.]]

This is a '''race''': the result depends on how the steps of the threads happen to interleave. A part of the program which uses shared data, and must not be run by two threads at the same time, is called a '''critical section'''.

== Mutexes ==

A '''mutex''' (''mutual exclusion'') is a lock which only one thread can hold at a time. A thread '''locks''' the mutex before the critical section, and '''unlocks''' it after. If another thread already holds it, [https://man7.org/linux/man-pages/man3/pthread_mutex_lock.3.html <code>pthread_mutex_lock(3)</code>] waits until it is unlocked.

<syntaxhighlight lang="c">
// In: <pthread.h>
int pthread_mutex_init(pthread_mutex_t *m, const pthread_mutexattr_t *attr);
int pthread_mutex_lock(pthread_mutex_t *m);
int pthread_mutex_unlock(pthread_mutex_t *m);
int pthread_mutex_destroy(pthread_mutex_t *m);
</syntaxhighlight>

A mutex must be set up with [https://man7.org/linux/man-pages/man3/pthread_mutex_init.3.html <code>pthread_mutex_init(3)</code>] before it is used, usually before the threads which use it are created. <code>attr</code> can choose other kinds of mutexes, or be <code>nullptr</code> for a normal one, which starts unlocked. When the mutex is no longer needed, [https://man7.org/linux/man-pages/man3/pthread_mutex_destroy.3.html <code>pthread_mutex_destroy(3)</code>] frees anything the mutex may hold.

To fix the counter, we add a mutex, and lock it around the increment:

<syntaxhighlight lang="c" line>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <pthread.h>
#include <unistd.h>

#define N 1000000

static long counter = 0;
static pthread_mutex_t lock;

static void *increment(void *arg)
{
(void) arg;
for (int i = 0; i < N; i++) {
pthread_mutex_lock(&lock);
counter++;
pthread_mutex_unlock(&lock);
}
return nullptr;
}

int main(void)
{
pthread_mutex_init(&lock, nullptr);

pthread_t a, b;
pthread_create(&a, nullptr, increment, nullptr);
pthread_create(&b, nullptr, increment, nullptr);
pthread_join(a, nullptr);
pthread_join(b, nullptr);

pthread_mutex_destroy(&lock);

char msg[256];
snprintf(msg, sizeof msg, "counter = %ld (expected %d)\n", counter, 2 * N);
write(STDOUT_FILENO, msg, strlen(msg));
return EXIT_SUCCESS;
}
</syntaxhighlight>

<syntaxhighlight lang="bash">
$ ./build/debug/app
counter = 2000000 (expected 2000000)
</syntaxhighlight>

The result is now correct, but locking has a cost: on our machine, the program became as much as 100 times slower. Every increment now also locks and unlocks the mutex, and while one thread holds it, the other has to wait. Critical sections should be kept as short as possible.

=== Under the hood: futex(2) ===

A <code>pthread_mutex_t</code> is, at its core, just an integer in the memory of the process. glibc uses three values:

{| class="wikitable"
! Value !! Meaning
|-
| 0 || Unlocked
|-
| 1 || Locked, and no other thread is waiting
|-
| 2 || Locked, and other threads may be waiting
|}

The processor has '''atomic''' instructions, which read and change a value in memory in a single step, so that no other thread can come in between. C provides them in <code><stdatomic.h></code>:

<syntaxhighlight lang="c">
// In: <stdatomic.h>. A is an atomic type, such as _Atomic uint32_t, and C the plain one, uint32_t.
// If *obj == *expected, sets *obj to desired and returns true.
// Otherwise, copies *obj into *expected and returns false.
bool atomic_compare_exchange_strong(volatile A *obj, C *expected, C desired);
// Sets *obj to desired, and returns its old value.
C atomic_exchange(volatile A *obj, C desired);
</syntaxhighlight>

Locking a free mutex is a single atomic instruction, which changes it from 0 to 1. This is the '''fast path''', and it needs '''no system call'''. The kernel is only needed when a thread has to wait, since only the kernel can put a thread to sleep and wake it up. For this, Linux provides the [https://man7.org/linux/man-pages/man2/futex.2.html <code>futex(2)</code>] (''fast user-space mutex'') system call:

<syntaxhighlight lang="c">
// In: <linux/futex.h> and <sys/syscall.h>. glibc has no wrapper for it.
long syscall(SYS_futex, uint32_t *addr, int op, uint32_t val, ...);
</syntaxhighlight>

{| class="wikitable"
! <code>op</code> !! What the kernel does
|-
| <code>FUTEX_WAIT</code> || If <code>*addr</code> is still equal to <code>val</code>, puts the thread to sleep, until another thread wakes it. Otherwise, returns right away
|-
| <code>FUTEX_WAKE</code> || Wakes up to <code>val</code> threads sleeping on <code>addr</code>
|}

For the threads of a single process, the <code>FUTEX_WAIT_PRIVATE</code> and <code>FUTEX_WAKE_PRIVATE</code> versions are a little faster. The kernel does not know anything about mutexes: it only keeps a list of sleeping threads for each address. Using the three values above:

* '''lock''': try to change the mutex from 0 to 1. If that worked, we hold it. Otherwise, set it to 2, to say that someone is waiting, and call <code>FUTEX_WAIT</code> with 2. When woken, try again.
* '''unlock''': set the mutex to 0. If it was 2, someone may be waiting, so call <code>FUTEX_WAKE</code> to wake one of them.

The check done by <code>FUTEX_WAIT</code> is what makes this work: if the mutex was unlocked between our failed attempt and the system call, the value is no longer 2, and the thread does not go to sleep waiting for a wake-up which already happened.

[[File:OS_Lab_5_-_futex.png|center|thumb|750px|Thread A locks a free mutex in user space, with no system call. Thread B finds it taken, marks it with 2 and sleeps in the kernel. When A unlocks it, it sees the 2, and asks the kernel to wake B, which then takes the mutex.]]

<div class="regula">'''Note:''' [https://man7.org/linux/man-pages/man3/pthread_join.3.html <code>pthread_join(3)</code>] also uses [https://man7.org/linux/man-pages/man2/futex.2.html <code>futex(2)</code>]. When [https://man7.org/linux/man-pages/man3/pthread_create.3.html <code>pthread_create(3)</code>] calls [https://man7.org/linux/man-pages/man2/clone.2.html <code>clone(2)</code>], it asks the kernel (with <code>CLONE_CHILD_CLEARTID</code>) to set a variable holding the TID of the thread to 0 when the thread ends, and to do a <code>FUTEX_WAKE</code> on it. [https://man7.org/linux/man-pages/man3/pthread_join.3.html <code>pthread_join(3)</code>] waits on that variable with <code>FUTEX_WAIT</code>.</div>

=== Deadlock ===

A program may need to hold several mutexes at once. If thread A locks mutex 5 and then waits for mutex 7, while thread B has locked mutex 7 and waits for mutex 5, neither of them can ever continue. This is a '''deadlock'''. The program does not crash, it just stops, using no CPU time at all.

[[File:OS_Lab_5_-_deadlock.png|center|thumb|550px|Thread A holds one lock and waits for the other, while thread B holds the other and waits for the first. Each waits for the other, forever.]]

The simplest way to avoid it is to always take the mutexes '''in the same order''', for example in increasing order of their number. Then no thread can hold a mutex while waiting for one that comes before it, so the threads can never wait for each other in a circle.

== Exercises ==

Write the program in a new copy of the project template. As a reminder from [[OS_Lab_1_-_Linux_setup._Bash_primer._C_primer#getting-the-template|the first lab]]:

<syntaxhighlight lang="bash">
mkdir -p ~/oslab && cd ~/oslab
curl -OL https://wiki.dcae.pub.ro/images/9/93/Os_lab_skeleton.zip
unzip -d lab05 Os_lab_skeleton.zip
</syntaxhighlight>

For this lab:

* As in the last labs, do not use the standard I/O library for output: build the text with [https://man7.org/linux/man-pages/man3/snprintf.3.html <code>snprintf(3)</code>] and [https://man7.org/linux/man-pages/man2/write.2.html <code>write(2)</code>] it.
* Check the value returned by [https://man7.org/linux/man-pages/man3/pthread_create.3.html <code>pthread_create(3)</code>], and remember that it is an error number, not -1.
* Use <code>time ./build/debug/app</code> to measure how long the program runs.

=== Bank transfers ===

A bank has 100 accounts, each starting with 1000. 8 threads, the '''tellers''', each make 1,000,000 random transfers between the accounts. Money only moves from one account to another, so at the end, the total must still be 100,000.

<syntaxhighlight lang="c">
#define N_ACCOUNTS 100
#define N_THREADS 8
#define N_TRANSFERS 1000000
#define INITIAL_BALANCE 1000

struct account {
pthread_mutex_t lock; // Not used until step 3
int balance;
};

static struct account accounts[N_ACCOUNTS];
</syntaxhighlight>

Each transfer picks two '''different''' accounts, <code>from</code> and <code>to</code>, and an amount between 1 and 100. If <code>from</code> has enough money, the amount moves from <code>from</code> to <code>to</code>. Otherwise, nothing happens. Use [https://man7.org/linux/man-pages/man3/rand_r.3.html <code>rand_r(3)</code>] for the random numbers, with a different seed for each thread: [https://man7.org/linux/man-pages/man3/rand.3.html <code>rand(3)</code>] keeps its state in a global variable, shared by all the threads.

# '''No locks.''' Write the tellers, and print the total after joining them. Run the program a few times: what happens to the total?
# '''One mutex for the whole bank.''' Lock a single global mutex around each transfer. The total is now correct. How long does the program take? Why is the <code>sys</code> time so large?
# '''One mutex per account.''' Instead of the global mutex, lock <code>accounts[from].lock</code>, then <code>accounts[to].lock</code>, do the transfer, and unlock them. Run the program: it will probably never end (Ctrl+C stops it). Explain why, in a comment.
# '''Lock ordering.''' Fix step 3 by always locking the account with the lower number first. The total must be correct, and the program should now be faster than in step 2. Why?

<syntaxhighlight lang="bash">
$ ./build/debug/app
total: 766978 (expected 100000)
$ ./build/debug/app
total: 751625 (expected 100000)
</syntaxhighlight>

<syntaxhighlight lang="bash">
$ time ./build/debug/app
total: 100000 (expected 100000)

real 0m0.304s
user 0m0.427s
sys 0m0.081s
</syntaxhighlight>

The first output is from step 1, and the second from step 4. The times depend on the machine, but step 4 should be clearly faster than step 2.

'''Bonus:''' Write your own mutex, on top of [https://man7.org/linux/man-pages/man2/futex.2.html <code>futex(2)</code>], as described in [[#Under the hood: futex(2)|the futex section]]:

<syntaxhighlight lang="c">
typedef _Atomic uint32_t mutex_t; // 0, 1 or 2, as above

void mutex_lock(mutex_t *m);
void mutex_unlock(mutex_t *m);
</syntaxhighlight>

Use it instead of <code>pthread_mutex_t</code> in step 4. The total must still be correct, and the time should be close to that of step 4.

'''Extra:''' Add an '''auditor''' thread, which checks the bank while the tellers work. Every 50 ms ([https://man7.org/linux/man-pages/man2/nanosleep.2.html <code>nanosleep(2)</code>]), it locks all the accounts, adds up their balances, unlocks them, and prints the total, which must always be 100,000. When the tellers are done, <code>main()</code> tells the auditor to stop through a global <code>atomic_bool</code> (from <code><stdatomic.h></code>): a variable which one thread writes while another reads it must be atomic.

<syntaxhighlight lang="bash">
$ ./build/debug/app
audit: 100000
audit: 100000
audit: 100000
audit: 100000
audit: 100000
audit: 100000
total: 100000 (expected 100000)
</syntaxhighlight>

* In which order must the auditor lock the accounts?
* Why must it hold all the locks at once? Try locking, reading and unlocking one account at a time instead: what totals do you get, and why?

@@ Linia 40: / Linia 40: @@
 * [https://www.youtube.com/watch?v=MUWAbpg1xLo CPU vs GPU vs TPU]
 * [https://www.youtube.com/watch?v=KVOc6369-Lo Flynn's Taxonomy: SISD, SIMD, MISD & MIMD]
 * [https://www.youtube.com/watch?v=PgDaJEjlBuI Multithreading vs Multiprocessing]
 * [https://www.youtube.com/watch?v=0ttx0AuNezo Superscalar vs Superpipelined]
 * [https://www.youtube.com/watch?v=6tbNew87fZU All CPU Architectures from von Neumann to Hybrid Multicores]

← Versiunea anterioară		Versiunea de la data 9 noiembrie 2026 09:33
(Nu s-a afișat o versiune intermediară efectuată de același utilizator)
Linia 1:		Linia 1:
	== Platforme laborator ==		== Platforme laborator ==

−	* [[Media:CID2_lab_1_2.pdf\|~~Platformă lab~~ 1+2]]	+	* [[Media:CID2_lab_1_2.pdf\|Lucrarea 1 + 2]]
		+	* [[Media:CID2_Platforma_APB_I.pdf\|Lucrarea 3]]
		+	* [[Media:CID2_Platforma_APB_II.pdf\|Lucrarea 4]]

@@ Linia 4: / Linia 4: @@
 * Lab 2 - [[OS Lab 2 - System calls. The initial stack]]
 * Lab 3 - [[OS Lab 3 - Files. Memory mapping]]
-* Lab 3 - [[OS Lab 4 - Processes. Signals]]
+* Lab 4 - [[OS Lab 4 - Processes. Signals]]
 === Old Lab Sessions (2025) ===

WikiLabs - Schimbări recente [ro]

Arhitectura Sistemelor de Calcul (curs)

Fișier:CID2 Platforma APB II.pdf

Circuite Integrate Digitale 2

Fișier:CID2 Platforma APB I.pdf

Fișier:OS Lab 5 - deadlock.png

Fișier:OS Lab 5 - futex.png

Fișier:OS Lab 5 - lost update.png

Fișier:OS Lab 5 - threads.png

OS Lab 5 - Threads. Mutexes

Operating Systems