Making your async code thread safe | .NET Tips 3

How to lock your C# code in an async way in C# and .NET

[dadsoul]

Probably do a follow-up to this about ReadWriterLockSlim. In most cases in the real world, you want reads to be concurrent, but block on writes. Another option would be covering a cache strategies for use in threading

[busra.tuncdan]

There is another thing to consider. İf you accidentally call the Release method from any other thread, semaphore allows it. To ensure that the Release call will be only within the owner thread, Mutex class can be used.

[AvenDonn]

Glad to see you took it down and reuploaded with my feedback implemented! It's important to lead by example, and it's a much better scenario to have a beginner ask "wait why is the Wait happening outside of the try?" and end up learning about this pitfall through inquisitive learning.

Good job Nick. I'm proud to share your videos with my coworkers consistently

[corso]

I would say it is really hard to explain smth like that in a very short period of time...but you did it wow.

[mbenedyk]

You missed one important thing, classic lock allows the same thread to re-enter synchronized section, however SemaphorSlim can be entered only specified amount of times. Semaphore slim is not the same lock as lock for sync code

[dannydyerschocolatehumuncl]

The algorithm be smoking crack if it thinks I'm gonna understand a word of this

[sigma_z]

Beautiful, thank you. Always learning something new from you Nick.

[UFOCurrents]

THIS... This is why I subscribed to Nick. Always something new and useful. 😎💪

[ix]

You're the man! This is so valuable advice 🥳

[diego_samano]

Waiting for a more detailed video about this 👍

[mykola]

why haven't you used a full version of youtube for this video? It is not convenient to use "shorts" for education - cannot rewind back, cannot change speed...

[patrick_]

You probably want to use the 2-integer constructor in this scenario, the second parameter being "maxCount": new SemaphoreSlim(1, maxCount: 1);

This prevents extra, erroneous calls to Release() from allowing concurrent access through the critical section. By specifying a max count, these extra calls to Release() will instead fail-fast (via exception).

Example:
var ss = new SemaphoreSlim(1); // SemaphoreSlim(1, 1);
await ss.WaitAsync();
ss.Release();
ss.Release(); // oops! .. now 2 concurrent accessors allowed
ss.Release(); // oops! .. now 3

It's an edge case, and probably TMI for the short video -- just FYI.

[dmitrykim]

Its not just a good idea to use finally block, its a must have

[noneofyourbusiness]

Any concerns with implementing IDisposable in the SemaphoreSlim class to do the release on dispose so it’s a bit cleaner to lock with a using block and avoid a try-finally block? It would also visually highlight what code is locked.

[rohanskoshti]

That's quite good information.. thank you

[federicoazzato]

There's a slightly behavior difference though. The lock keyword allows reentrant code to enter the critical region several times in the call stack, while with SemaphoreSlim you'd need some sort of way to tell the current task already is allowed to enter the region without attempting to wait for an exhausted semaphore.

[AvenDonn]

Suggestion for the future: how about a quick intro to TPL DataFlow? (ActionBlock)

Or is it "outdated" nowdays?

[Dpaz]

love this! Tha'ts why I subscribed!

[theroboman]

me writing rust: "wait, not being thread safe was even an option?"

[protox]

Re-upload, eh? Still going to point to AsyncLock in the AsyncEx library. ;)