SpinLock.POC

[beef9999]

No description provided.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

chenbo seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[qicosmos]

you'd better add a new example for testing spinlock, don't modify the current case.
And you need to sign our Contributor License Agreement before we can accept your contribution.

[beef9999]

... It's not a contribution. It's a demo to show the bug.

[RainMark]

... It's not a contribution. It's a demo to show the bug.

Ok, we will try to test it, and can you supply the backtrace of segment fault?

[ChuanqiXu9]

This might be a mis-use. We need to pass an executor in the start point of the async chain. But the diagnostic message from the library side is not friendly indeed. We would try to enhance it. Thanks for reporting.

[RainMark]

coScopedLock need a executor to reschedule current coroutine to avoid the others be blocked, but this demo code use syncAwait to start a lazy task (without executor), so segment fault occurred

you can use ScopedSpinLock to avoid the coroutine yield or pass a executor to syncAwait

eg:

async_simple::coro::syncAwait(start(io_context, "127.0.0.1", "9980").via(executor));

[beef9999]

I think what I need is a mutex(based on coroutine). I didn’t find it in the code.

[beef9999]

And what kind of executor should I use there?

[RainMark]

I think what I need is a mutex(based on coroutine). I didn’t find it in the code.

ok, mutex is working on

[RainMark]

And what kind of executor should I use there?

just use async_simple::executors::SimpleExecutor for test

[beef9999]

Is coScopedLock + executor sufficient to run my test? Because you said mutex is still under development … I’m a little confused

[RainMark]

Is coScopedLock + executor sufficient to run my test? Because you said mutex is still under development … I’m a little confused

yes

[beef9999]

I have updated the code and added the Executor, now this test case is able to run.

But as long as I increase the concurrency (coroutine number) at the client side, its QPS would continue to fall.

Concurrency	QPS
1	167K
2	155K
8	97K
32	78K

[beef9999]

Looks like the coScopedLock + executor is not working as expected as a mutex does. Something is blocked.

[RainMark]

collectAll run multi coroutines in same thread asynchronously, looks like you want all coroutines parallel on all thread, try to use collectAllPara？

[ChuanqiXu9]

Thanks for reporting. I've got a similar results. And my conclusions are:

1. SpinLock is not performance friendly. When I remove SpinLock and use atomic counter, the QPS wouldn't decrease if we increase the conccurency.
2. SimpleExecutor is not good for performance too. We stated it is only used for testing in the docs. The direct impact would be: when we unlock a lock, we send the task to resuming a coroutine to the executor. But the executor wouldn't resume that immediately. The schedule strategy is simply random.

A condition variable here might be better.

[ChuanqiXu9]

@beef9999 Given there is no other comment. I am going close this one. Thanks for contributing.