-
Notifications
You must be signed in to change notification settings - Fork 49
Improved data write logic to avoid reading dirty data #517
Improved data write logic to avoid reading dirty data #517
Conversation
a62e896
to
6ed7a49
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thx
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if all these lock guard can be treated as member of processor. This will get rid of the unlock(..) things, and move lock guard to a lambda then UNUSED(l).
not important , LGTM
Good idea, This is a good way to manage Gard Lock. let me think about that later and deal with everything together. but not in this PR. Thanks . |
This reverts commit 4e56a74.
test error log:
|
This reverts commit 4e56a74.
We are using
ConcurrentHashMap
to solve the performance issues of concurrent writes.The current write logic may cause dirty data to be read, for example:
Thread A : -----> read -> lock -> write
Thread B : read----------------------------> lock -> write
If thread A terminates first, it will cause thread B to read dirty data.
changed to :
Thread A : lock -----> read -> write -> unlock
Thread B : lock - > read-----------------------------> write -> unlock