Resync: brand-new synchronization approach

announcements
1

Hey there, everyone! I've been working on my project Resync for the last week.

It's a library/framework for composable synchronization primitives. You can select independently how to lock, how to retry and how to poison (and even do it or not).

Quick example:

// tiny critical section,
// instant locking required,
// guaranteed no panics in critical section
type FastMutex<T> = resync::Mutex<T,
    resync::lock::Atomic,
    resync::retry::Busy,
    resync::poison::NoPoison
>;

// high contention,
// writers starvation possible,
// critical section is huge,
// panics in critical section are possible
type ComplexRwLock<T> = resync::Sharex<T,
    resync::lock::Shield<resync::lock::Futex>, // <-- updated to match current API
    // resync::retry::Yield, // it's default
    // resync::poison::StdPoison // it's default
>;

// we are in OS kernel,
// resource is shared with interrupt handlers,
// we have our own poisoning policy implemented
type GlobRes<T> = resync::Sharex<T,
    resync::lock::Irq<resync::lock::Atomic>,
    resync::retry::Busy, // or own retry policy with project-specific yielding
    MyPoisoningPolicy // must implement `resync::api::PoisonPolicy`
>;

Crate published on crates.io. It already has more than hundred downloads and a fully green CI pipeline across all targets! I have spent a lot of time on it: the crate is tested on Linux, Windows and macOS, on stable, beta and nightly Rust and with all possible feature sets.

I'm planning to publish 1.0 soon and finish tests and benchmarks.

I really need your feedback! I'm a sole developer and it's my first big open-source project, s so a star, an issue report, or even a quick comment would be incredibly helpful.

Thanks for your attention!

2

My first thought is: why is this not using the established lock_api? Even if the answer is “because their traits are incompatible with the features I offer”, it would be good to document that answer, because lock_api is so established in the ecosystem.

3

That’s a reasonable argument, however, I’ve added a clearly visible banner at the very top of the crate’s README, which explains the incompatibility. If you’d like to learn more about the reasons for the incompatibility, or if you have any suggestions about where this information should be placed, I’d be very grateful.

4

I didn’t see that note because it isn't in the library documentation, but that’s fair. However, it doesn’t really explain why they’re incompatible. As someone who might be picking a library to use, I’d like to know what the fundamental incompatibility is — what would I be getting from your library that I can’t get if lock_api traits were used?

5

Thank you for the note; I will definitely duplicate the note in the crate documentation and release a separate text with a detailed description of the reasons for the incompatibility.

6

resync::batteries::lock::fake::FakeError means the same as ! / core::convert::Infallible, am I right? You could reuse one of those types or make it an empty enum for space savings.

Separately, I'm alarmed by reposting interface of resync under crate name su as well.

7

Yes, but rustc doesn't think so (I'll change it in future release, but I don't think it's a good idea, I'll think about it more).

About su, It's my other crate which in plans, but not implemented yet. in it's code I tested resync, so old dependency saved redundantly.

8

I have updated the documentation and duplicated the information about the incompatibility with lock_api on docs.rs and in the crate’s guidebook. I will describe the rationale behind the decision later as a separate chapter in the guidebook.