You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
This logic could have few customization points, but on my opinion exists only such real world mutex usage scenarios:
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.
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)
We want to schedule code after unlock to the some specific scheduler (possible with both: async and sync unlock)
The text was updated successfully, but these errors were encountered:
Example
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:
The text was updated successfully, but these errors were encountered: