threads/118910: Multithreading problem

[David Xu]

Daniel Eischen wrote:
> On Fri, 21 Dec 2007, David Xu wrote:
> 
>> Daniel Eischen wrote:
>>
>>> I don't think it is as big a change as you think it is.  We already
>>> have several layers of priorities (interrupt, time-share, idle, ?).
>>> All threads belong to these classes.  As long as priority inheritence
>>> works, there should be no problems.  The problems seem to occur when
>>> we try to inject artificial priorities into threads, like using
>>> msleep().  I think we are better off just letting threads run based
>>> on their own base priority and whatever their inherited priority is.
>>>
>>
>> For test purpose, you may try to ignore thread priority parameter
>> in msleep(), I didn't test this, but it does change the FreeBSD
>> behavior. I don't know any side effect since I am unable to test
>> all applications in the world, maybe you can start a project to hack
>> it ?
> 
> I'll take a look at trying that.  I should be able to figure out
> how to get msleep to ignore the priority.  But I think the missing
> piece is the interrupt routines - they need to create their mutexes
> and CVs so that they are more like priority ceiling mutexes.  Any
> thread (even non-interrupt threads) that takes one of these mutexes
> needs to have its priority raised as well as blocking the interrupt
> (for fast interrupts anyway) until the mutex is released.
> 

kernel mutex is already priority inheritence, the spin lock mutex
looks like a priority protected mutex which raises thread priority to
highest possible(critical section), and can not be preempted.
so there is no priority problem in mutex.
The only problem I can think of is  semaphore-like msleep/wakeup pair 
which does not do priority inheritance, if a higher priority thread
is blocked in msleep, priority of another thread holding the resources
is not boosted.