[Swift language features] Revisit thread safety of ref counting in projections

[vitek-karas]

from: #2964 (comment)

Dispose in our projections should be resilient to parallel calls from multiple threads - this means it needs to correctly handle checking for already released references.

[rolfbjarne]

Dispose in our projections should be resilient to parallel calls from multiple threads

Making only Dispose thread-safe doesn't change much, because then any other instance method would still have a race condition.

If thread A does:

var obj = new SwiftObject ();
Console.WriteLine (obj.GetSwiftDescription ());
obj.Dispose ();

and thread B the same thing:

var obj = new SwiftObject ();
Console.WriteLine (obj.GetSwiftDescription ());
obj.Dispose ();

then even if Dispose itself is thread-safe, any of the two calls to GetSwiftDescription() might access freed memory.

One way around this could be to use a read-write lock, where each usage of the internal handle acquires the read lock, and then Dispose acquires the write lock. This way Dispose won't run until nobody else is using the internal handle.

The downside is that every instance method would need locking, slowing down the bindings.

FWWI I can't remember hearing about any other API binding/projection that does this kind of safety guarantee / locking.

[jkotas]

I can't remember hearing about any other API binding/projection that does this kind of safety guarantee / locking.

The base class library APIs like Socket or FileStream do provide this kind of safety guarantee / locking. I agree that it comes with extra overhead. It is typically done using SafeHandle.

[rolfbjarne]

It is typically done using SafeHandle.

Ah I see, so it's basically a refcounted handle. That would work.