Skip to content
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

Make AddTypeHandlerImpl in SqlMapper thread safe #2107

Conversation

mobilebilly
Copy link

As discussed in issue #1815, the current implementation of SqlMapper.AddTypeHandlerImpl is not thread-safe. When typeHandlers is cloned during concurrent access to this method, a race condition occurs because each thread maintains its own copy of typeHandlers. This can result in handlers added by some threads being lost. This fix addresses the issue to ensure thread safety.

Additionally, we propose to obsolete below overload version of AddTypeHandlerImpl:

void AddTypeHandlerImpl(Type type, ITypeHandler? handler, bool clone)

Also suggest making all overloads of AddTypeHandlerImpl non-public, as their method names indicate that they are intended for internal implementation, but that could be handled separately in the future.

@billrob
Copy link
Contributor

billrob commented Oct 31, 2024

Hey @mgravell I don't think a clone is necessary. I can run this review if confirmed to not be necessary. I see this is old code from 2015. There is comment // use clone, mutate, replace to avoid threading issues that doesn't work the author thought it would.

var newCopy = clone ? new Dictionary<Type, ITypeHandler>(snapshot) : snapshot;
lock (typeHandlers)
{
if (typeHandlers.TryGetValue(type, out var oldValue) && handler == oldValue) return; // nothing to do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you do this as a ConcurrentDictionary instead of locking?

@mgravell
Copy link
Member

mgravell commented Oct 31, 2024

The existing code perhaps has risk of lost updates, but this API is not expected to be used aggressively on-the-fly, so in reality: this shouldn't be a problem. If we're concerned, then some simple synchronization in those few methods should be fine.

The proposed changes, however, look to be more unsafe - in that it allows competing threads doing routine query work (not adding handlers) to attempt to read the dictionary while it is being mutated (only the write is guarded by the lock). This can break in much worse ways.

The old code deliberately avoided this by never allowing the "live" dictionary to be mutated.

Potentially this can be mitigated using things like concurrentdictionary, but: I wonder if this would thing can be much simpler by just locking on a separate sync token for the duration of any admin operations, but maintaining the snapshot/mutate/swap approach.

@mgravell
Copy link
Member

Regarding the "impl" method; damn, that method was never intended to be public. Separately, I'll deal with that (in a different PR). Just pretend that public API doesn't exist.

@billrob
Copy link
Contributor

billrob commented Oct 31, 2024

@mgravell Right, this PR code currently isn't ideal. I can run this PR to get it into a good shape. Or if @mobilebilly is okay with it, I can just do my own PR tidying this section up. Even the existing "clone operation" can run afoul of issues during the iteration for the clone.

I was thinking about setting it as a ConcurrentDictionary<T,K> and removing all the clone parameters and updating to TryAdd / TryGet. As far as two handlers for the same type coming in a threaded situation, do you want the first or last to win (first would be easiest)?

@mgravell
Copy link
Member

I've proposed #2129, which I think does everything needed in a safer way, with fewer moving parts. Thoughts?

@mgravell
Copy link
Member

dammit appveyor, stop messing with pgsql!

@mgravell
Copy link
Member

Closing out with preference to #2129

@mgravell mgravell closed this Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants