Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 handlelock
takes this handle and a function, and sends aLock
message to the mutexAccepted
message, otherwise, it enqueues the PID of the process attempting to lockf mutex.inner
Unlock
message, the mutex process sends anUnlock_accepted
lock
returnsOk ()
, the mutex process checks the queue and starts looping againget
is identical tolock
but instead of mutating the inner it returns a deep copy of ittry
immediately return an error if the mutex is locked, as opposed to waitingBoth 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:
create
to take an optionalpriority
that's applied to the mutex process?unsafe_get
andunsafe_set
?Marshal
or usingObj
? The latter seems tricky but less expensive