You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment we use Atomic, Mutex, and Weak throughout the Riot runtime to do synchronization of work across the schedulers.
This style of programming doesn't play very well with Riot's process model, but it can be more straightforward to code in than synchronizing things via message-passing directly.
For example, in building a Hashmap that needs to lock, but should only really lock the current process, we can't use Mutex.protect – this would potentially lock the entire scheduler.
Shadowing Mutex with a version that is process-based would be ideal, to allow for a similar programming model and at the same time making it harder to accidentally lock an entire scheduler.
Implementation Notes
I'd probably start with making a Mutex be a small process, so creating a Mutex spawn_links it. Operations on top then are implemented as messages to/from that process. This ensures that a call to Mutex.lockactually becomes an interrupt point for the process.
Another good option here is a 'value Rw_lock.t type for making it possible to have multiple readers or a single writer to a value.
The text was updated successfully, but these errors were encountered:
Hello @leostera, may I give this one a try ?
I drafted a small genserver based implementation, I would need to round some corners but I think it matches quite nicely the description you made in the issue.
At the moment we use Atomic, Mutex, and Weak throughout the Riot runtime to do synchronization of work across the schedulers.
This style of programming doesn't play very well with Riot's process model, but it can be more straightforward to code in than synchronizing things via message-passing directly.
For example, in building a Hashmap that needs to lock, but should only really lock the current process, we can't use
Mutex.protect
– this would potentially lock the entire scheduler.Shadowing
Mutex
with a version that is process-based would be ideal, to allow for a similar programming model and at the same time making it harder to accidentally lock an entire scheduler.Implementation Notes
I'd probably start with making a Mutex be a small process, so creating a Mutex spawn_links it. Operations on top then are implemented as messages to/from that process. This ensures that a call to
Mutex.lock
actually becomes an interrupt point for the process.Another good option here is a
'value Rw_lock.t
type for making it possible to have multiple readers or a single writer to a value.The text was updated successfully, but these errors were encountered: