Can we further optimize the scheduling order of goroutines in sync.Mutex?

[fliter]

In sync/mutex.go, there is a comment like the following:

```go

// Mutex fairness.
//
// Mutex can be in 2 modes of operations: normal and starvation.
// In normal mode waiters are queued in FIFO order, but a woken up waiter
// does not own the mutex and competes with new arriving goroutines over
// the ownership. New arriving goroutines have an advantage -- they are
// already running on CPU and there can be lots of them, so a woken up
// waiter has good chances of losing. In such case it is queued at front
// of the wait queue. If a waiter fails to acquire the mutex for more than 1ms,
// it switches mutex to the starvation mode.

```

I wonder if the waiter here refers to the goroutine at the head of the queue, or any goroutine in the queue? 

If any goroutine in the queue causes the lock to enter starvation mode, but the next goroutine that acquires the lock immediately is not it but the one at the head of the queue, whether it is better to change it to who makes the lock enter starvation mode and who immediately acquires the lock ?

Thanks for discussion and answers.

[Ian Lance Taylor]

On Sat, Jun 3, 2023 at 12:35 AM fliter <imc...@gmail.com> wrote:
>
>
> In sync/mutex.go, there is a comment like the following:
>
> ```go
> // Mutex fairness.
> //
> // Mutex can be in 2 modes of operations: normal and starvation.
> // In normal mode waiters are queued in FIFO order, but a woken up waiter
> // does not own the mutex and competes with new arriving goroutines over
> // the ownership. New arriving goroutines have an advantage -- they are
> // already running on CPU and there can be lots of them, so a woken up
> // waiter has good chances of losing. In such case it is queued at front
> // of the wait queue. If a waiter fails to acquire the mutex for more than 1ms,
> // it switches mutex to the starvation mode.
> ```
>
>
> I wonder if the waiter here refers to the goroutine at the head of the queue, or any goroutine in the queue?

In that comment "waiter" refers to the goroutine at the head of the
queue. When a mutex is unlocked, it wakes up the first waiter, if
any.

Ian

[fliter]

Thanks for your answer. But I wonder if the elements behind the queue may wait for a very long time? Can we maintain a waiting time after entering the queue for each coroutine, and acquire locks from high to low

Thanks again.

[Robert Engels]

That is implicit since the list of waiters is ordered. 

On Jun 5, 2023, at 7:08 AM, fliter <imc...@gmail.com> wrote:

Thanks for your answer. But I wonder if the elements behind the queue may wait for a very long time? Can we maintain a waiting time after entering the queue for each coroutine, and acquire locks from high to low

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/8a9dd408-a4cc-45e6-b806-e8a25cb4e309n%40googlegroups.com.

[Ian Lance Taylor]

On Mon, Jun 5, 2023 at 5:08 AM fliter <imc...@gmail.com> wrote:
>
> Thanks for your answer. But I wonder if the elements behind the queue may wait for a very long time? Can we maintain a waiting time after entering the queue for each coroutine, and acquire locks from high to low

The queue is already FIFO ordered. The goroutine at the head of the
queue is the one that has been in the queue the longest. I don't see
what benefit we would get from recording a waiting time with the
queue.

Ian

> 在2023年6月4日星期日 UTC+8 01:07:52<Ian Lance Taylor> 写道：
>>
>> On Sat, Jun 3, 2023 at 12:35 AM fliter <imc...@gmail.com> wrote:
>> >
>> >
>> > In sync/mutex.go, there is a comment like the following:
>> >
>> > ```go
>> > // Mutex fairness.
>> > //
>> > // Mutex can be in 2 modes of operations: normal and starvation.
>> > // In normal mode waiters are queued in FIFO order, but a woken up waiter
>> > // does not own the mutex and competes with new arriving goroutines over
>> > // the ownership. New arriving goroutines have an advantage -- they are
>> > // already running on CPU and there can be lots of them, so a woken up
>> > // waiter has good chances of losing. In such case it is queued at front
>> > // of the wait queue. If a waiter fails to acquire the mutex for more than 1ms,
>> > // it switches mutex to the starvation mode.
>> > ```
>> >
>> >
>> > I wonder if the waiter here refers to the goroutine at the head of the queue, or any goroutine in the queue?
>>
>> In that comment "waiter" refers to the goroutine at the head of the
>> queue. When a mutex is unlocked, it wakes up the first waiter, if
>> any.
>>
>> Ian
>

[fliter]

I didn't realize that it was already implicitly sorted by time. Thanks for answering