Do not use any locking - #1384
Conversation
I have pulled in the code from https://github.com/VSadov/NonBlocking to test out. This will actually be collapsed into the minimum requirements for an IntPtr dictionary.
| // TODO: remove from the dictionary | ||
| // or, better yet, do this in a single op |
There was a problem hiding this comment.
This is the reason I originally switched away from the dictionary. There is no easy way to have an atomic comparison between the key and value. I only want to remove if the key AND value match.
The reason for this is just because the native side will have created a brand new object at the same location, and we mustn't remove it form the dictionary. We only do that if this is our handle AND our object.
To work around this for now, I do an UPDATE, and replace the value with a dummy object. This means that the dictionary always grows. Maybe with the new dictionary type, this update operation could be a TryRemove(key, value) and it checks both before removing.
|
|
||
| // volatile read to make sure we read the element before we read the _newTable | ||
| // that would guarantee that as long as _newTable == null, entryValue cannot be forwarded. | ||
| var entryValue = Volatile.Read(ref entry.value); |
There was a problem hiding this comment.
We could check the value here, and then jump out if it didn't match.
TODO: THIS MUST BE DONE CORRECTLY!!!
|
|
from @kekekeks
|
|
This is probably not needed after #1817 Either way, this is not the right approach. |
1 participant
Description of Change
It appears that using locks triggers a paint...
So, we can't do that. I have pulled in the code from https://github.com/VSadov/NonBlocking to test out. This will actually be collapsed into the minimum requirements for an IntPtr dictionary.
Bugs Fixed
None.
Behavioral Changes
None.
PR Checklist