-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: concurrency conflict because of Memory Order #3532
base: master
Are you sure you want to change the base?
fix: concurrency conflict because of Memory Order #3532
Conversation
…LiteWallt creation
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 prefer to use lock(this)
Memory barrier is enough. |
we don't want to lock the thread. We want to lock objects we are using or that needs to be locked. |
MemoryBarrier is lighter than lock, only affects Out-of-Order Execution of CPU and complier re-order. |
…QLiteWallet creation
@@ -71,6 +72,7 @@ public NEP6Wallet(string path, string password, ProtocolSettings settings, strin | |||
accounts = new Dictionary<UInt160, NEP6Account>(); | |||
extra = JToken.Null; | |||
} | |||
Thread.MemoryBarrier(); |
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.
If the object is not yet constructed, how it can be dangerous in multi-thread?
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.
Because there are some use-cases of Wallet
that wallet is a field of a class(for example, RpcServer
) and it is loaded on needed. i.e. Wallet field is null before Wallet
load.
A wallet load operation will assign a Wallet
instance to this field, so there is such a case that can happen:
Thread 1 load a wallet and assign wallet instance to wallet field, but this instance is partial constructed because of Out-of-Order execution of CPU;
Thread 2 can see this partial constructed instance.
This is a classic concurrency problem:
In Java, this can be solved by declaring a field as final
;
In Linux kernel, WRITE_ONCE
and READ_ONCE
is often used.
In C#, this can be solved by declaring a field as volatile
, but this fix uses memory barrier.
It's hard to trigger this problem on x86 machines.
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.
The variable is not assigned yet, only after is constructed, so you need to do this after this assignation, not before
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.
The variable is not assigned yet, only after is constructed, so you need to do this after this assignation, not before
In another thread‘ view, a wallet may assigned to a Wallet field, then this wallet instance’s fields are assigned to this instance because of out of order execution
@@ -84,6 +86,7 @@ public NEP6Wallet(string path, string password, ProtocolSettings settings, JObje | |||
{ | |||
this.password = password.ToSecureString(); | |||
LoadFromJson(json, out Scrypt, out accounts, out extra); | |||
Thread.MemoryBarrier(); |
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.
same here
working as expected |
@shargon need you to decide |
I can't see the problem it fixes |
Description
Wallets may created later after the process started, and these Wallets implementations use lock to protect inner structures, however, no proper synchronization is used when the object is initialized.
According to the C# memory model, a thread may see a partial constructed object or there are some inflight operations when another thread is creating an Object(especially the CPU with relax consistency model).
https://learn.microsoft.com/en-us/archive/msdn-magazine/2012/december/csharp-the-csharp-memory-model-in-theory-and-practice#thread-communication-patterns
Type of change
Checklist: