Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

flat combining for async_mutex #529

Open
MBkkt opened this issue May 24, 2023 · 0 comments
Open

flat combining for async_mutex #529

MBkkt opened this issue May 24, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@MBkkt
Copy link

MBkkt commented May 24, 2023

Example

task1:
start execution on thread_pool 1
lock mutex
critical section 1
unlock mutex
continue execution on thread_pool 1

task2:
start execution on thread_pool 2
lock mutex
critical section 2
unlock mutex
continue execution on thread_pool 2

In a lot of cases doesn't matter where will be executed critical section (in the thread_pool 1 or 2).

So if they are executed in the same time (and one lock wait another unlock), would be nice to have ability to execute cs in the batch.
It's also known as flat combining.

Implementation could rely on async unlock:
The current thread using symmetric transfer to execute next critical section.
The code after unlock scheduled to some scheduler before symmetric transfer return.

I implemented same logic for yaclib library https://github.com/YACLib/YACLib/blob/main/include/yaclib/coro/mutex.hpp#L135
(Implementation doesn't reschedule continuation if no other critical section and has ability to restrict the count of critical section which will be executed via symmetric transfer)

This logic could have few customization points, but on my opinion exists only such real world mutex usage scenarios:

  1. We don't care where will be executed critical section, but it's important for us that executor (scheduler?) before and after critical section the same. I think it's most popular usage.
  2. We want to execute critical section and the code after it in the same thread (I think current implementation after fix Mutex::unlock serialize code after it #449 will do it, sync unlock do it)
  3. We want to schedule code after unlock to the some specific scheduler (possible with both: async and sync unlock)
@ispeters ispeters added the enhancement New feature or request label May 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants