[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
|
|
Subscribe / Log in / New account

Restartable sequences

Restartable sequences

Posted Jul 15, 2015 10:20 UTC (Wed) by dgm (subscriber, #49227)
In reply to: Restartable sequences by riking
Parent article: Restartable sequences

I think the whole idea of the approach (using a memory region) is to avoid making syscalls, basically for performance. This way the scheduler can just compare the Instruction Pointer to detect if a restart is needed. Note that the critical section should run much more often than the scheduler for this to be a net win.

Maybe another (naive?) approach would be to share a memory pointer with the kernel where the thread can publish a restart address. Say something like

set_atomic_restart(&ptr);

with ptr some memory owned by the thread big enough for a pointer. With that, an application can do

ptr=&&some_label;

when entering a critical section, and ptr=NULL; when leaving. If the scheduler needs to pre-empt the thread and finds that ptr has a non-null value, execution would restart at ptr instead of the saved IP.


to post comments

Restartable sequences

Posted Jul 15, 2015 18:42 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

I thought the whole point of using futexes for locks in NPTL was so that no syscalls were necessary for them in the uncontended case, either, in which case this whole thing is no faster than the locky approach (but is a lot more complex).

Restartable sequences

Posted Jul 15, 2015 19:54 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Futexes have to use atomic operations for their fastpaths and they are quite slow. You can't avoid them because your thread might be migrated to another CPU, so non-atomic memory access will likely ruin everything.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds