You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a possible race condition in between Proxied read and test for reference counter = 0 in Proxied. A thread resolving weak reference could have read non-null Proxied into register and preemted, and after resume it will access invalid memory. Proxied is null on resume, but this check is passed.
The only good protection against it that comes to my mind is to introduce integer counter in proxy and increment it when reading it. This counter must be strongly associated with Proxied and modified atomically together with it using cmgxchg8b, cmpxchg16b or mutex.
This way reading Proxied becomes atomic. Reader thread technically reads value (Saved_Proxied := Proxy.Proxied), but cannot legally do anything useful with it, even dereference, until it puts a lock. Thread that is going to destroy object, first zeroes Proxy.Proxied, so that new threads can no longer appear, then waits for every remaining reader thread to abort. Then it can safely deallocate memory.
The text was updated successfully, but these errors were encountered:
There is a possible race condition in between Proxied read and test for reference counter = 0 in Proxied. A thread resolving weak reference could have read non-null Proxied into register and preemted, and after resume it will access invalid memory. Proxied is null on resume, but this check is passed.
The only good protection against it that comes to my mind is to introduce integer counter in proxy and increment it when reading it. This counter must be strongly associated with Proxied and modified atomically together with it using cmgxchg8b, cmpxchg16b or mutex.
Pseudocode for resolving weak reference:
Pseudocode for zeroing Proxied:
This way reading Proxied becomes atomic. Reader thread technically reads value (Saved_Proxied := Proxy.Proxied), but cannot legally do anything useful with it, even dereference, until it puts a lock. Thread that is going to destroy object, first zeroes Proxy.Proxied, so that new threads can no longer appear, then waits for every remaining reader thread to abort. Then it can safely deallocate memory.
The text was updated successfully, but these errors were encountered: