why idle-queue use std::mutex, not use strategized Lock as golang?

[sxstd001]

	why idle-queue use std::mutex,  not use strategized Lock as golang?  

[Darksonn]

You will need to provide more information for me to be able to answer this. What exactly is Go doing?

[sxstd001]

golang Lock:
if lock-fail do some spinning , not direct block;
std::atomic_u8 state: locked / unlock / sema_wait;
lock():
cas 2times => cas + cpu_pause(30) 4times => cas+thread::yeild 1times => sema_wait;

[Darksonn]

The reason is that nobody has provided a really good justification for why we should do something else. The standard mutex is the default choice, and using the standard mutex (which is not always std::sync::Mutex in Tokio, due to the parking_lot flag) should always be preferred over a bespoke custom mutex implementation unless there is a really good justification for it.

Also, I don't know which queue you are referring to. We don't have a queue of idle tasks.

Next time you ask a question, you should provide much more information. For this question, it would have been appropriate to:

1. Include a direct link to the code in Tokio.
2. Include a direct link to the code in the Go runtime.
3. Include an explanation of what Go is doing, rather than using a non-standard phrase such as "strategized lock" that yields no useful results if you look it up.