[NSWI004] a03 - locks and finished threads

Petr Tuma petr.tuma at d3s.mff.cuni.cz
Mon Nov 16 15:34:17 CET 2020


Hello Krystof,


> It seems to me that any code working with data structures of threads and scheduler is a possible critical section (e.g. thread_yield - depends on implementation but the same thread can be started at the same time on multiple cpus?). Therefore, we are supposed to implement spin locks in this assignment, right? I am not sure if it is so clear we should do it since it is not mentioned in the assignment instructions and nobody has asked about it. If so, we can use any gcc built-in functions, right? Are there any good ways to debug that the locking works correctly?

This assignment is about cooperative threads on a single CPU, so essentially you do not need synchronization at this time. This will come in the next assignment, but since we will only test on one CPU, very often simply disabling interrupts across the critical sections will be enough.

As for the GCC built in atomics, many will work reasonably well, some might expand into a library call and then you will see a missing symbol during linking. (I've just tested `__atomic_fetch_add` and it compiled fine, into a loop with `ll` and `sc`.)

> Moving on to my other question, is it necessary to keep track of all finished threads (for a given process)? It seems weird to me since creating a lot of threads can make the kernel run out of memory and it seems not very memory efficient but how else can we determine that a particular thread has finished? If thread A wants to wait for thread B via thread_join(B) and B finishes sooner than thread A even calls thread_join(B), then how can the kernel tell that A can continue...

The `thread_join` call should only be used once on each thread, and that is actually the place where you will want to free any information kernel was tracking about the thread.

Petr


More information about the NSWI004 mailing list