1) op was more computationally intensive than atomic read-write
2) update wasn't on the same computer, which will force us to think of network latencies, packet losses, partitions, between DB client and actual server.
Interesting! After spawning 100 goroutines, I noticed a similar failure rate of ~1%. I added the pessimistic implementation here and did a time difference comparison. I didn't notice much difference in the total time taken between the two.
I am not sure I understand your pessimistic locking implementation?
`atomiCounter.Add(1)`
Lots of architecture now-a-days support this op in a single step - so it's not possible for multiple threads to see and update intermediate values. I don't remember the exact instruction, but I remember reading about it in college.
That might be the reason you didn't see much of a difference.
I think a way to simulate would be to use a normal variable and do an update with a RW-Mutex lock. That's very pessimistic :)
We have a read heavy resource where we have implemented pessimistic locks. Going optimistic might just unlock some performance.
Definitely, worth a shot.
Interesting read!
I think the failure rate might be higher if
1) op was more computationally intensive than atomic read-write
2) update wasn't on the same computer, which will force us to think of network latencies, packet losses, partitions, between DB client and actual server.
I might need to check if some enterprise or OS DB has done such analysis. Optimistic still is a better fit for use-cases involving simple updates, I have often used DDB's optimistic locking at work: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.OptimisticLocking.html
Agreed with both of your points. Thanks for sharing this article. I will try my hand at this implementation with DynamoDB.
Interesting! After spawning 100 goroutines, I noticed a similar failure rate of ~1%. I added the pessimistic implementation here and did a time difference comparison. I didn't notice much difference in the total time taken between the two.
https://github.com/mrmagicpotato007/go-concurrency-exercises/blob/main/optimisticvspessimistic/main.go
I am not sure I understand your pessimistic locking implementation?
`atomiCounter.Add(1)`
Lots of architecture now-a-days support this op in a single step - so it's not possible for multiple threads to see and update intermediate values. I don't remember the exact instruction, but I remember reading about it in college.
That might be the reason you didn't see much of a difference.
I think a way to simulate would be to use a normal variable and do an update with a RW-Mutex lock. That's very pessimistic :)
Thanks vipin my understanding of atomic counter was incorrect after using mutex i can see clear overhead with the mutex approach.