On Fri, Apr 16, 2021 at 04:33:51PM +0100, Wedson Almeida Filho wrote: > On Fri, Apr 16, 2021 at 04:19:07PM +0200, Peter Zijlstra wrote: > > Does this also not prohibit constructs where modification must be done > > while holding two locks, but reading can be done while holding either > > lock? > > I don't believe it does. Remember that we have full control of the > abstractions, > so we can (and will when the need arises) build an abstraction that provides > the > functionality you describe. For the read path, we can have functions that > return > a read-only guard (which is the gateway to the data in Rust) when locking > either > of the locks, or when showing evidence that either lock is already locked > (i.e., > by temporarily transferring ownership of another guard).
But will this remain syntactically readable/writable by mere humans ? I mean, I keep extremely bad memories of having tried to write a loop oconcatenating at most N times a string to another one, where N was a number provided on the command line, with the compiler shouting at me all the time until I blindly copy-pasted random pieces of unreadable code from the net with a horribly complicated syntax that still resulted in the impossibility for me to check for memory allocation before failing. So I'm wondering how complicated that can become after adding all sort of artificial protections on top of this :-/ > Note that this is > another area where Rust offers advantages: read-only guards (in C, if you > take a > read lock, nothing prevents you from making changes to fields you should only > be > allowed to read); But I'm happily doing that when I know what I'm doing. What you call a read lock usually is in fact a shared lock as opposed to an exclusive lock (generally used for writes). For me it's perfectly valid to perform atomic writes under a read lock instead of forcing everyone to wait by taking a write lock. You may for example take a read lock on a structure to make sure that a field you're accessing in it points to stable memory that is only modified under the write lock, but the pointer itself is atomically accessed and swapped under the read lock. > In fact, this is also an advantage of Rust. It would *force* developers to > lock/unlock the RCU lock before they can access the protected data. I'm really afraid by languages which force developers to do this or that. Many bugs in C come from casts because developers know their use case better than the compiler's developers, and result in lack of warnings when the code evolves, leaving pending bugs behind. What is important in my opinion is to let developers express what they want and report suspicious constructs, not to force them to dirtily work around rules that conflict with their use case :-/ Willy
