Skip to content

Issues with rust-level lock_and_signal #2781

Closed
@bblum

Description

@bblum

The lock_and_signal implemented in libcore/sys.rs has two issues:

  • Being killed, or even yielding at all, while holding one of these locks can cause deadlock, especially if another task runs on the same core that tries to take the lock. This will bite us hard as soon as the compiler starts inserting yield-checks.
    -- Easy solution: Add a preempt_disable counter in the rt scheduler, à la linux spinlocks, that it checks every yield
    -- Hard solution: Make the scheduler know how to reschedule to the owner of a lock on the same core. (Still requires unkillable, I think)
  • fn lock(fn() -> T) -> T is a cute interface, but doesn't support lock interleaving. Add acquire/release.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-runtimeArea: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflowsC-enhancementCategory: An issue proposing an enhancement or a PR with one.E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions