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

Riot-friendly mutex #75

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Riot-friendly mutex #75

wants to merge 8 commits into from

Conversation

FayCarsons
Copy link

@FayCarsons FayCarsons commented Apr 18, 2024

I volunteered for issue #46, but have been blocked on this and haven't heard from the person previously working on it, so I thought I'd pick it up :)

There were a few decisions I made that I'm not super sure of so definitely a draft! Feedback v much appreciated!

It seems to work, though I have observed the mutex process hanging if there are a lot of processes trying to get the lock. Not sure if that's specific to this or a larger issue w/ Riot.

The basic idea (which was partly inspired by the previous implementation) is:

  • create spawns a looping process behind the scenes and returns a handle
  • lock takes this handle and a function, and sends a Lock message to the mutex
  • If unlocked, the mutex process responds with an Accepted message, otherwise, it enqueues the PID of the process attempting to lock
  • Once the lock is acquired, the inner value (contained in the handle) is set to f mutex.inner
  • The locker sends an Unlock message, the mutex process sends an Unlock_accepted
  • lock returns Ok (), the mutex process checks the queue and starts looping again
  • get is identical to lock but instead of mutating the inner it returns a deep copy of it
  • Functions prefixed with try immediately return an error if the mutex is locked, as opposed to waiting

Both the locking process and the mutex process monitor each other to prevent deadlocks that could be caused if one crashes while the other waits. The mutex process handles double locks/unlocks, other invalid messages, with a Failed (reason) message. Every function in the API, besides unsafe get and set, return a result so the locking thread can handle failures.

Some questions that came up while writing this:

  • Should the mutex process fail on an invalid message?
  • Do we want create to take an optional priority that's applied to the mutex process?
  • do we want unsafe_get and unsafe_set?
  • Should cloning be done by serializing and deserializing via Marshal or using Obj? The latter seems tricky but less expensive
  • Does the error type need to be a polymorphic variant? I noticed a lot of the other errors in the lib are and figured that was for a reason but idk further than that
  • tests?

@FayCarsons
Copy link
Author

@leostera has this been fixed? If not I'd be happy to clean up the code or condense my summary of it if that would help it get pushed. I'd really like to be able to use Riot & Minttea in performance sensitive apps

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant