Suggestion: lock() for an entire context

[birkenfeld]

The lock method on tuples is a great idea for getting multiple resources locked.

However, sometimes I find that I need to lock all resources in a cx.shared and was wondering if it could also provide a lock method that returns a struct with the same field names, but all field tpes are &mut T.

Not sure if resources that aren't lockable should be present in that struct or not.

[perlindgren]

Yes, that should be doable, and quite useful. Thanks for the suggestion we will look into it.

[birkenfeld]

Nice! I'm really loving the 0.6 changes, btw, it's a big improvement in ergonomics.

[perlindgren]

I'm looking at a possible implementation. It looks feasible, a struct needs to be created and passed to the closure containing &mut R references. This struct should be declared locally in the generated module (e.g. under the name Shared). I'm not sure the name needs to be visible to the end user if just using the . notation but if one wants to destruct the passed resource struct it needs to.

[perlindgren]

There is a crux still to be solved. For soundness, RTIC ensures that you cannot get multiple (mutable) references by locking a field of the shared resources twice. The way its implemented is zero-cost, where the check is done by the compiler at compile time. The resource proxy is consumed by the lock. I'm playing around with this now, if lock is implemented for the "parenting" structure then we should be able to have this working. Some details regarding passing of cfgs needs to be ironed out as well.

[perlindgren]

I put together a pre-rfc. https://github.com/rtic-rs/rfcs/issues/53

[perlindgren]

There is now a corresponding POC:

https://github.com/rtic-rs/cortex-m-rtic/tree/lockall

There is still an outstanding issue regarding the resource proxy for the lock-all API. It currently exposes the priority (Priority type). At some point, we deemed that to be risky, I don't recall now exactly how it can potentially be exploited. In any case that problem should be solvable if we decide to include the lockall API in the RTIC 0.6 release. Please go ahead an try it. The examples/lockall*.rs should give you an idea how it can be used.

[perlindgren]

Small fix, the Priority is no longer leaked. https://github.com/rtic-rs/cortex-m-rtic/tree/lockall

[birkenfeld]

I've tried the current branch and it works fine for me. Thanks!

[eflukx]

Is there a plan to merge this code?

[korken89]

@eflukx In its current state, no. The code is UB so a redesign is needed if it were to be merged.