Re: Thread starvation with mutex

Luke Elliott wrote:
> In the example the first thread does:
> 
> lock mutex
> usleep
> unlock mutex
> 
> As someone pointed out (off list I think), if the sleep is replaced with 
> a busy loop, the second thread will run.

Ah...  penny drops.  That's why it fails.

> Now clearly the original example is totally unrealistic, but is the fact 
> that the second thread never runs something that could happen in the 
> "real world"? I guess that depends on whether the thread blocked on a 
> mutex can assume at some point it will get woken ... (Interestingly, AIX 
> apparently shows the same behaviour as NPTL.)

As someone else pointed out, Solaris is similar.  Perhaps it shows
this behaviour too.

Yes, this sort of thing does happen in the "real world" but rarely.
It is one of those annoying things that you ignore until you notice a
problem in testing, and then you do a workaround.  It's too messy and
difficult to find all the possible starvation cases in principle and
design them out.

As I said, Linux had a problem with locks and starvation for kernel
code that was trying to read the clock, while another task was reading
the time regularly from userspace calls.

That's a very similar example, except that the starvation was actually
due to CPU hardware, one CPU starving a spinlock on another CPU.  Just
goes to show it is quite a fundamental patten.

-- Jamie