I have a global process list and each process has a thread list. The lists themselves are sorted in three separate data structures: a hash table for fast pid/tid lookups, a familial tree with siblings, children and parents to maintain relationships and a linked list for linear operations. (ag, it works).
Previously my kernel would lock itself if any operations needed to be done on any important structures. Now that I'm removing these giant locks, I'm thinking of using the following technique:
Process list:
1. A single reader-writer lock (rwlock) for the global process list in case of insertion and deletion of process - occuring infrequently.
2. Each entry in the list having a rwlock for modifications to the selected process.
3. The rwlock in 2 does not belong to the process but to the list itself. So if a process crashes and is cleaned, no contention problems arise from deleting a lock which could be in use... as the lock remains and will be dealt with correctly.
Thread list:
1. A single rwlock for the thread list in case of deletion and insertion.
2. Each entry having a rwlock belonging to the entry in case of local thread modifications.
Each process or thread will be "checked out" of the respective lists by locking the rwlock and having the requested reading/modifications done. Each process or thread will then be checked back in by releasing the lock.
No global operations (insertion or deletion) can be done while an individual thread or process is checked out.
The important thing to remember is that in one process, one thread may be accessing(locking) important kernel data while another thread decides to divide by 0 in userland and the process is marked as crashed and all threads are cleaned up - possibly leaving the kernel data locked. SO Particular sections of the code will still need to be protected by global/non-interruptable protections.
Um yeah. Has anyone else dealt with issues like this and what do you do? Is there a better way?
