[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Agustina Arzille
Subject: Re: [PATCH 1/2] Implement basic sleeping locks for gnumach.
Date: Sun, 29 Jan 2017 21:11:12 -0300

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]