Great video. Everything very intuitively described, I liked video about atomics by Fedor Pikus also. Great job! Waiting for your videos next year, thanks.
17:18 "you do the modulo to get the index of the block and then you do the remainder to get the position of the data in the block", obviously he meant to say "division" (ie quotient), not modulo. (*(p[i/N]))[i%N] or something, i do not remember precedence of dereference
Please correct me, because I want to be wrong about this: Isn't there a race condition between rcu_read_lock and synchronize_rcu? lets say a reader grabs generation N, and the current ref count is 0; there is some time between the execution of the generation load and the refcount increment. In this time between generation load and refcount increment, synchronize_rcu is called and gets current generation N and increments it. Before the reader thread has a change to get its increment in, the writer sees that refcount is 0 and proceeds to release the memory. the reader finally comes back to life and attempts to use the handle it was guaranteed to have life time support for but its resource is no longer alive. However improbable, can this race condition occur?
I don't think this is the case. If you look at the synchronize_rcu implementation that was shown, it will store the current generation value N in last_gen and will do the cleanup of each generation from last_gc_gen to last_gen excluded. So if a reader grabs generation N the writter will do the cleanup up to N - 1. I think synchronize_rcu will not cleanup the memory of the current and previous generations in the code that was shown.
@@guillaumecourrier7489 Please correct me, what if synchronize_rcu is called twice between the execution of the generation load and the refcount increment?
@@jjaychen I was thinking you could do a double check, before getting the handle and after getting the handle, and return the handle only when the generation count has not changed. That way, you can guarantee the increment was registered. Somewhat similar to what the SeqLock does?
I had the same question. I think a loop that does a double check makes sense. It would guarantee correctness, and If the generation isn't updated often, then most of the time the generation numbers would match and so the double check loop wouldn't be too costly either.
Great video. Everything very intuitively described, I liked video about atomics by Fedor Pikus also. Great job! Waiting for your videos next year, thanks.
Wonderful talk! Thanks!
Thank you! This talk was amazing :D
Glad it was helpful!
17:18 "you do the modulo to get the index of the block and then you do the remainder to get the position of the data in the block", obviously he meant to say "division" (ie quotient), not modulo. (*(p[i/N]))[i%N] or something, i do not remember precedence of dereference
Thank you really great video.
Please correct me, because I want to be wrong about this: Isn't there a race condition between rcu_read_lock and synchronize_rcu? lets say a reader grabs generation N, and the current ref count is 0; there is some time between the execution of the generation load and the refcount increment. In this time between generation load and refcount increment, synchronize_rcu is called and gets current generation N and increments it. Before the reader thread has a change to get its increment in, the writer sees that refcount is 0 and proceeds to release the memory. the reader finally comes back to life and attempts to use the handle it was guaranteed to have life time support for but its resource is no longer alive. However improbable, can this race condition occur?
I don't think this is the case. If you look at the synchronize_rcu implementation that was shown, it will store the current generation value N in last_gen and will do the cleanup of each generation from last_gc_gen to last_gen excluded. So if a reader grabs generation N the writter will do the cleanup up to N - 1. I think synchronize_rcu will not cleanup the memory of the current and previous generations in the code that was shown.
@@guillaumecourrier7489 Please correct me, what if synchronize_rcu is called twice between the execution of the generation load and the refcount increment?
@@Ricky-kx6pfCurious about this, too. Did you figure it out?
@@jjaychen I was thinking you could do a double check, before getting the handle and after getting the handle, and return the handle only when the generation count has not changed. That way, you can guarantee the increment was registered.
Somewhat similar to what the SeqLock does?
I had the same question. I think a loop that does a double check makes sense. It would guarantee correctness, and If the generation isn't updated often, then most of the time the generation numbers would match and so the double check loop wouldn't be too costly either.
57:13 "Readers can crash", I hope it's not because of undefined behavior.
I know that will works, because i write language based, asked data scientist to check our backend,