Re: [PATCH 1/2] Implement basic sleeping locks for gnumach.

[Agustina Arzille]

On 2017-01-29 17:44, Samuel Thibault wrote:
> Agustina Arzille, on Sun 29 Jan 2017 16:46:45 -0300, wrote:
>
> There is just one thing I'm a bit afraid of: the code is assuming that
> the only reason why the locker thread is awakened is that it was given
> the mutex control. Is that guaranteed?

Well, the locker thread checks the wait_result value: If it's 
THREAD_AWAKENED,
it assumes that control of the mutex was transferred to it; otherwise, 
it
assumes it was interrupted. I *think* that's good enough.

> It'd allow to avoid simple_lock() completely on that side. I've been
> thinking about avoiding simple_lock() completely, but it's not easy
> without modifying thread_block/thread_wakeup_one deeply. So for now
> let's keep the simple_lock, and then yes thread_sleep is enough.

Ah, I see what you mean. Yeah, I was trying to get rid of the interlock,
but I don't think it's possible, since you need to serialize access to
the sleep queue.

> The comment above is misleading then: "The waiter was interrupted and
> left". Does it mean that *at best* there were some waiters but they 
> were
> interrupted?

Yes, I think it could be explained better. What it means is:

- The owner thread believes that there's at least a waiter, since the 
state
  is KMUTEX_CONTENDED, therefore, it acquires the interlock, preventing 
any
  other thread from adding itself to the wait queue.

- However, thread_wakeup_one reports that no thread was awakened. This 
means
  that any waiter(s) that were sleeping on the mutex were interrupted. 
As such,
  it must reset the state and make it available.