I was struggling to get hold of the concepts from book as I had no background in parallel programming and was taking advance course on multicore profgramming and now after this i got it finally some stuff
you are awesome to make such a confusing topic understandable and more importantly - intuitive. This really deserves many many more likes. thanks again !!
Great explanations! I appreciate you highlighting the relevance of learning this. My professor goes straight to showing us proofs and how to check for Seq consistency and linearization without explaining why we are learning this in the first place.
Bro this is such a good video man. We are studying concurrency systems right now and I find this module so hard to conceptualize, I wish you did a full series 😭
Thanks! Glad that you find the video helpful. Haha, I can see how it can be confusing. Let me know which topics you find difficult to understand. I'll consider talking about them in the future.
For the sequential consistency exercise (around 22:25), isn't the answer yes it can be? T1: W(1) -> W(2) T2: R1=2 -> R2=1 It can be ordered as follows to satisfy sequential consistency: R1=2 -> W(1) -> R2=1 -> W(2) This satisfies the thread ordering
You are making the assumption that the initial value of the key is 2 in the above example - if that is the case, yes! I think the presenter assumes that the initial value is 0 in all examples.
thanks for the video, very informative! one question though... for a read that initiates before a write completes, that read *could* choose to see or not see the effect of the write, according to time 30:16 onward, for linearizable consistency. However, wouldn't it be more accurate if such read should arbitrate to not seeing the write? do we have such constraint on linearizability consistency, or it is stronger than linearizability?
Why such a write should NOT be seen by the concurrent read? The fundamental issue is that in a distributed system with asynchrony and crash, a read cannot actually tell whether such a write is concurrent or not. So in short, linearizability doesn't have such a constraint.
Correct. It doesn't satisfy either. The reason is a bit off. You need a bit more argument to say when you won't be able to construct such an ordering. Your answer is on the right track, but only a part of the story. :)
I was struggling to get hold of the concepts from book as I had no background in parallel programming and was taking advance course on multicore profgramming and now after this i got it finally some stuff
This is such a great video to understand consistency models such as Linearizability and Sequential Consistency. TYSM
you are awesome to make such a confusing topic understandable and more importantly - intuitive. This really deserves many many more likes. thanks again !!
Great explanations! I appreciate you highlighting the relevance of learning this. My professor goes straight to showing us proofs and how to check for Seq consistency and linearization without explaining why we are learning this in the first place.
Bro this is such a good video man. We are studying concurrency systems right now and I find this module so hard to conceptualize, I wish you did a full series 😭
Thanks! Glad that you find the video helpful.
Haha, I can see how it can be confusing. Let me know which topics you find difficult to understand. I'll consider talking about them in the future.
This is awesome. Great explanation with examples. love it.
YOU SAVE MY LIFE!!!!!!!!
Excellent video! Thanks for shedding on light on the differences between serializability vs linearizability.
Thanks! A minor point: I'm focusing on sequential consistency here, not serializability. See this nice post for the comparison: jepsen.io/consistency
For the sequential consistency exercise (around 22:25), isn't the answer yes it can be?
T1: W(1) -> W(2)
T2: R1=2 -> R2=1
It can be ordered as follows to satisfy sequential consistency:
R1=2 -> W(1) -> R2=1 -> W(2)
This satisfies the thread ordering
You are making the assumption that the initial value of the key is 2 in the above example - if that is the case, yes! I think the presenter assumes that the initial value is 0 in all examples.
That's correct. I assumed the initial value is 0, so the first read shouldn't return a 2 in the OP's answer.
Great tutorial!
Do you have a video for quiescent consistency?
Unfortunately, no
This is great
Brilliant
thanks for the video, very informative! one question though... for a read that initiates before a write completes, that read *could* choose to see or not see the effect of the write, according to time 30:16 onward, for linearizable consistency. However, wouldn't it be more accurate if such read should arbitrate to not seeing the write? do we have such constraint on linearizability consistency, or it is stronger than linearizability?
Why such a write should NOT be seen by the concurrent read? The fundamental issue is that in a distributed system with asynchrony and crash, a read cannot actually tell whether such a write is concurrent or not. So in short, linearizability doesn't have such a constraint.
Awesome
The exercise is not linearizable nor sequentially consistent because R2 cannot read 1 since it comes after a W2 in the same thread, correct?
Correct. It doesn't satisfy either. The reason is a bit off. You need a bit more argument to say when you won't be able to construct such an ordering.
Your answer is on the right track, but only a part of the story. :)
I think its because r1 already returned 2, which means r1 happens after w2. R2=1 violates both linearizability and seq consistency
C