julien-leclercq
commented
9 months ago 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.
leostera
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
Mutexwith 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.ttype for making it possible to have multiple readers or a single writer to a value.