Akatsuki-Misaki/ArchiSteamFarm
1
0
Fork 0
mirror of https://github.com/JustArchiNET/ArchiSteamFarm.git synced 2026-01-06 17:10:13 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
643fd4b4ac93d2a7799d8a00a63ac65240afb362
ArchiSteamFarm/packages/Nito.AsyncEx.4.0.1/lib/net40/Nito.AsyncEx.Enlightenment.xml

40 lines
2.0 KiB
XML
Raw Normal View History

Fix async/await with ConcurrentHashSet Now this is a nice bug that was found accidentally by ArchiBoT... ReaderWriterLockSlim() is very decent solution, but it's thread-based, and we're using our ConcurrentHashSet in mixed async/sync context. This means that if we use something like: foreach (var item in concHashSet) { await AnythingAsync().ConfigureAwait(false); } It's totally possible that we'll request read lock as thread 1, and release the read lock as thread 2, which will lead to RWLock exception => System.Threading.SynchronizationLockException: The read lock is being released without being held. Fortunately it looks like we didn't have any scenario like this in ASF, as this was possible only when we async/await while enumerating over ConcurrentHashSet, so that specific bug didn't affect ASF codebase (yet). Still, I must fix this as current implementation is not thread-safe, so our HashSet is in fact not concurrent in the first place. I analyzed possible solutions and there are basically 3: either using ConcurrentDictionary and wrapping around it, replacing lock with SemaphoreSlim, or using third-party AsyncReaderWriterLock from StephenCleary. SemaphoreSlim entirely kills the concept of multiple readers one writer, and could affect performance negatively, moreover - it doesn't support upgreadable lock scenario we have with ReplaceIfNeededWith(). Concurrent dictionary would be nice if I didn't have that awful memory hit from storing mandatory pointless value, plus I don't really like concept of wrapping around conc dictionary if I can simply use it right away and drop my conc hashset entirely. AsyncReaderWriterLock seem to be really well written, and works on Mono + should be compatible with .NET core in the future, so we should go for it as it's the best bet both performance-wise and memory-wise. This brings another package dependency and changes a bit backend of ConcurrentHashSet
2017-02-07 20:14:51 +01:00
<?xml version="1.0"?>
<doc>
<assembly>
<name>Nito.AsyncEx.Enlightenment</name>
</assembly>
<members>
<member name="T:Nito.AsyncEx.EnlightenmentVerification">
<summary>
Verifies platform enlightenment.
</summary>
</member>
<member name="M:Nito.AsyncEx.EnlightenmentVerification.EnsureLoaded">
<summary>
Returns a value indicating whether the correct platform enlightenment provider has been loaded.
</summary>
</member>
<member name="F:Nito.AsyncEx.Internal.PlatformEnlightenment.AsyncEnlightenment.DenyChildAttach">
<summary>
The <c>TaskCreationOptions.DenyChildAttach</c> value, if it exists; otherwise, <c>0</c>.
</summary>
</member>
<member name="F:Nito.AsyncEx.Internal.PlatformEnlightenment.ExceptionEnlightenment.CaptureAndThrow">
<summary>
A delegate that will call <c>ExceptionDispatchInfo.Capture</c> followed by <c>ExceptionDispatchInfo.Throw</c>, or <c>null</c> if the <c>ExceptionDispatchInfo</c> type does not exist.
</summary>
</member>
<member name="F:Nito.AsyncEx.Internal.PlatformEnlightenment.ExceptionEnlightenment.PrepForRemoting">
<summary>
A delegate that will call <c>Exception.PrepForRemoting</c>, or <c>null</c> if the method does not exist. This member is always <c>null</c> if <see cref="F:Nito.AsyncEx.Internal.PlatformEnlightenment.ExceptionEnlightenment.CaptureAndThrow"/> is non-<c>null</c>.
</summary>
</member>
<member name="M:Nito.AsyncEx.Internal.PlatformEnlightenment.ExceptionEnlightenment.TryAddStackTrace(System.Exception)">
<summary>
Attempts to add the original stack trace to the <see cref="P:System.Exception.Data"/> collection.
</summary>
<param name="exception">The exception. May not be <c>null</c>.</param>
</member>
</members>
</doc>
Reference in New Issue Copy Permalink