[haiku-development] Proposing kernel patch: mutexes/priorities

This is a multipart message in MIME format.

Hey!

In relation to bug ticket 8007 [1] I propose a kernel patch (attached 
to this mail) which implements:
* Kernel mutex waiting lists sorted by waiter priority (as opposed to 
strict FIFO before)
* Priority boosting for kernel mutexes
* For the boosting to work, the thread struct keeps a list of mutexes 
held by the thread

The priority boosting works as follows: if a thread A with priority X 
holds a mutex and another thread B with priority Y tries to acquire it, 
and Y > X, then the priority of A gets temporarily boosted to Y+1. As 
soon as A releases the mutex it gets back its old priority X. (except A 
still holds more mutexes with higher-priority threads waiting.. then it 
gets the priority of the next-highest-priority waiter plus one).

In the discussion of the bugticket, axeld comments that "why should a 
low priority thread be able to preempt a high priority thread just 
because it acquired a mutex?". While I understand the reasoning, I 
think one also has to see the other side: it already happens 
implicitly. When a low-priority threads holds a mutex needed by a high-
priority thread it effectively blocks the high-priority thread from 
working... it gets scheduled more often, but all it can do is stall and 
waste CPU cycles. Even though there is no explicit priority change, it 
happens implicitly and causes freezing. So IMO it makes sense to boost 
the low-priority thread so it can finish whatever it does quickly and 
release the lock again.

This patch does not solve the issues in ticket #8007, only partially. 
It does resolve the excessive mutex-wait-times (at least on one of my 
systems) seen in the scheduling_recorder output attached to the bug 
ticket. However, now the problem is shifted to the second part: waiting 
for port read cvar. The system can still freeze for a while with just 
StyledEdit, but now it's not due to waiting for mutexes, but waiting 
for ports. This needs to be solved as well...

Also, there is still one known problem with the patch: sometimes the 
system deadlocks when booting (in the last stage, the rocket icon 
already lighted), it always happens in the net_server thread, which got 
its priority boosted and then freezes the rest of the boot process. I 
have not yet investigated why that is, whether it is a problem in 
net_server that just gets uncovered by this patch or if it's a problem 
with the functionality of this patch itself. I will look into that.

Would be nice if some Haiku kernel developer could take a closer look 
at the patch to see if it's alright. It's the first time I've worked on 
something inside the Haiku kernel, I hope I didn't break things :)

Greetings,
Julian

[1] http://dev.haiku-os.org/ticket/8007



 
 

 
 
 
 
 
 
 





Other related posts: